DUDLEY  KNOX  LIBRARY 
NAVAL  POSTGRADUATE  SCHOOL 
MONTEREY  CA  93943-5101 


Naval  Postgraduate  School 
Monterey,  California 


Thesis 


Real-Time  Modeling  of  Cross  -Body  Flow 

for  Torpedo  Tube  Recovery  of  the 

Phoenix  Autonomous  Underwater  Vehicle  (AUV) 


by 


Kevin  Michael  Byrne 
March  1998 


Thesis  Advisor: 
Second  Reader: 


Don  Brutzman 
Robert  B.  McGhee 


Approved  for  public  release;  distribution  is  unlimited. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  lor  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  lor  reviewing  instruction,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services.  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson 
Davis  Highway.  Suite  1204.  Arlington.  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Proiect  (0704-0188)  Washington  DC  20503. 


1.  AGENCY  USE  ONLY  (leave  blank) 


2.  REPORT  DATE 

March  1998 


3.  REPORT  TYPE  AND  DATES  COVERED 

Master's  Thesis 


4.  TITLE  AND  SUBTITLE 

REAL-TIME  MODELING  OF  CROSS-BODY  FLOW  FOR  TORPEDO 
TUBE  RECOVERY  OF  THE  PHOENIX  AUTONOMOUS 
UNDERWATER  VEHICLE  (AUV) 


6.  AUTHOR(S) 

Kevin  Michael  Byrne 


5.  FUNDING  NUMBERS 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Postgraduate  School 
Monterey,  CA     93943-5000 


8.   PERFORMING  ORGANIZATION 
REPORT  NUMBER 


9.   SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 


11.  SUPPLEMENTARY  NOTES 


The  views  expressed  in  this  thesis  are  those  of  the  author  and  do  not  reflect  the  official  policy  or  position  of 
the  Department  of  Defense  or  the  U.S.  Government. 


12a.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited. 


12b.  DISTRIBUTION  CODE 


13.  ABSTRACT 

A  virtual  world  provides  an  exceptional  resource  for  the  testing  and  development  of  an  Autonomous 
Underwater  Vehicle  (AUV).  The  difficulties  associated  with  the  underwater  environment  are  numerous  and  complex. 
In  order  to  properly  verify  vehicle  results  in  the  laboratory  such  a  world  must  accurately  model  the  physics  associated 
with  the  vehicle,  its  submerged  hydrodynamics  characteristics,  and  interactions  with  the  environment.  Environmental 
effects  such  as  wave  motion,  currents,  and  flow  forces  created  by  bodies  moving  through  the  water  can  cause 
unpredicted  performance  variations  and  failures  in  the  ocean  environment.  The  current  Phoenix  AUV  virtual  world 
includes  steady-state  ocean  currents,  but  does  not  take  into  account  the  environmental  effects  of  waves  and  flow  forces 
induced  by  adjacent  vehicles  (such  as  a  moving  submarine  docking  target). 

This  work  provides  a  thorough  real-time  simulation  of  these  complex  factors  using  physically  based  models. 
The  problem  is  broken  down  into  wave  motion  effects,  submarine-induced  flow  fields,  and  virtual  sensors  to  improve 
AUV  motion  control.  Simulated  testing  is  performed  across  a  range  of  easy  to  worst-case  scenarios  in  order  to  justify 
assumptions.  Extensive  testing  using  virtual  sensors  is  used  to  develop  adequate  control  algorithms  in  the  presence  of 
turbulent  cross-body  flow. 

The  result  of  this  research  is  an  enhanced  virtual  world  which  more  accurately  depicts  the  ocean  environment, 
along  with  the  models  and  control  algorithms  required  to  design  and  operate  an  AUV  (continued  next  page) 


14.  SUBJECT  TERMS 

Virtual  environment,  simulation-based  design,  cross-body  flow,  autonomous  underwater 
vehicle  (AUV),  platform-independent  simulation. 


15.  NUMBER  OF  PAGES 

228 


16.  PRICE  CODE 


17.  SECURITY  CLASSIFICATION 
OF  REPORT 

Unclassified 


18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

Unclassified 


19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 

Unclassified 


20.  LIMITATION  OF  ABSTRACT 
UL 


NSN  7540-01-280-5500 


Standard  From  298  (Rev.  2-89) 

Prescribed  by  ANSI  Std.  239-18 

298-102 


-1- 


Unclassified 

SECURITY  CLASSIFICATION  OF  THIS  PAGE 


13.  ABSTRACT  (Continued) 

during  submarine  launch  and  recovery.  A  platform  independent  approach  to  virtual  environment  simulation  is 
presented  through  the  use  of  the  Virtual  Reality  Modeling  Language  (VRML)  and  Java.  Finally,  simulation  test  results 
provide  strong  evidence  that  AUV  control  with  actual  cross-body  flow  sensors  can  enable  stable  navigation,  first 
through  a  turbulent  flow  field  and  then  for  subsequent  docking  with  a  moving  submarine. 


Standard  Form  298,  (Reverse) 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 
Unclassified 


-11- 


DUDLEY  KNOX  LIBRARY 
NAVAL  POSTGRADUATF  SCH< 
MONTEREY,  CA  93943 


Approved  for  public  release;  distribution  is  unlimited 


REAL-TIME  MODELING  OF  CROSS-BODY  FLOW 

FOR  TORPEDO  TUBE  RECOVERY  OF  THE 

PHOENIX  AUTONOMOUS  UNDERWATER  VEHICLE  (AUV) 


Kevin  Michael  3yrne 

Lieutenant,  United  States  Navy 

B.S.,  State  University  of  New  York  Maritime  College,  1991 


Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 

Master  of  Science  in  Computer  Science 

from  the 

Naval  Postgraduate  School 
March  1998 


ABSTRACT 

A  virtual  world  provides  an  exceptional  resource  for  the  testing  and  development  of  an 
Autonomous  Underwater  Vehicle  (AUV).  The  difficulties  associated  with  the  underwater 
environment  are  numerous  and  complex.  In  order  to  properly  verify  vehicle  results  in  the  laboratory 
such  a  world  must  accurately  model  the  physics  associated  with  the  vehicle,  its  submerged 
hydrodynamics  characteristics,  and  interactions  with  the  environment.  Environmental  effects  such  as 
wave  motion,  currents,  and  flow  forces  created  by  bodies  moving  through  the  water  can  cause 
unpredicted  performance  variations  and  failures  in  the  ocean  environment.  The  current  Phoenix  AUV 
virtual  world  includes  steady-state  ocean  currents,  but  does  not  take  into  account  the  environmental 
effects  of  waves  and  flow  forces  induced  by  adjacent  vehicles  (such  as  a  moving  submarine  docking 
target). 

This  work  provides  a  thorough  real-time  simulation  of  these  complex  factors  using  physically 
based  models.  The  problem  is  broken  down  into  wave  motion  effects,  submarine-induced  flow  fields, 
and  virtual  sensors  to  improve  AUV  motion  control.  Each  set  of  forces  are  thoroughly  analyzed  and 
realistically  simulated  in  real-time  through  the  algorithms  developed.  In  order  to  maintain  real-time 
response,  perturbations  in  the  flow  field  caused  by  the  AUV  itself  are  assumed  to  be  negligible. 
Simulated  testing  is  performed  across  a  range  of  easy  to  worst-case  scenarios  in  order  to  justify 
assumptions.  Extensive  testing  using  virtual  sensors  is  used  to  develop  adequate  control  algorithms  in 
the  presence  of  turbulent  cross-body  flow. 

The  result  of  this  research  is  an  enhanced  virtual  world  which  more  accurately  depicts  the 
ocean  environment,  along  with  the  models  and  control  algorithms  required  to  design  and  operate  an 
AUV  during  submarine  launch  and  recovery.  A  platform  independent  approach  to  virtual  environment 
simulation  is  presented  through  the  use  of  the  Virtual  Reality  Modeling  Language  (VRML)  and  Java. 
Finally,  simulation  test  results  provide  strong  evidence  that  AUV  control  with  actual  cross-body  flow 
sensors  can  enable  stable  navigation,  first  through  a  turbulent  flow  field  and  then  for  subsequent 
docking  with  a  moving  submarine. 
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I.    INTRODUCTION 

A.   BACKGROUND 

The  end  of  the  cold  war  has  shifted  the  international  balance  of  military  strength.  Today's 
United  States  Navy  is  undergoing  a  major  reorganization.  Our  naval  mission  has  moved  from  an 
open-water  strategy  to  littoral  warfare.  A  paradigm  shift  of  such  proportions  brings  with  it  the  need 
for  new  strategies,  technologies,  and  insights.  Meanwhile  public  pressure  demands  reduced  military 
funding  and  resources.  These  factors  are  creating  challenging  situations  as  a  smaller  military  attempts 
to  meet  broader  range  of  missions  with  fewer  resources.  Highly  capable,  low-cost  underwater  robots 
provide  promising  new  capabilities  which  might  be  used  to  enhance  military  readiness  while  relieving 
the  stress  associated  with  broader  mission  goals. 

While  robots  are  not  a  valid  solution  for  every  problem  domain,  mine  warfare  is  a  mission 
area  that  is  extremely  pertinent.  Mine  warfare  is  a  naval  tactic  that  can  be  easily  used  by  any  potential 
enemy.  It  is  a  low-cost,  low-risk  measure  which  is  very  effective  and  hard  to  oppose. 

The  Naval  Postgraduate  School  (NPS)  Autonomous  Underwater  Vehicle  (AUV)  Research 
Group  is  actively  working  to  provide  a  solution  to  this  defense  problem.  The  Phoenix  AUV  is  a  low- 
cost  robot  designed  for  mine  detection.  One  of  the  research  group's  goal  is  to  demonstrate  that 
autonomous  underwater  robots  are  a  solution  which  can  provide  underway  units  the  ability  to  search 
areas  for  mines  and  obstacles  from  a  safe  distance.  Figure  1.1  shows  the  Phoenix  AUV  deployed 
during  in-water  testing. 

In  addition  to  in-water  robot  testing,  the  NPS  has  a  fully  operational  virtual  environment 
which  is  used  for  simulation-based  design  (SBD).  This  provides  a  low-cost  development  environment 
for  many  possible  robot  technologies,  reducing  both  project  cost  and  time  to  deliver  operational 
devices.  The  virtual  environment  gives  researchers  the  ability  to  thoroughly  test  future  devices  in 
diverse  operating  conditions. 
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Figure  1.1.  The  Phoenix  AUV  deployed  for  in 
water  testing  (Brutzman,  1998). 

B.       MOTIVATION 

Virtual  environments  provide  a  realistic  arena  for  the  testing  and  development  of  future 
vehicle  technologies.  It  is  necessary  to  ensure  that  simulations  are  physically  based  and  accurate  in 
order  to  support  proper  testing  and  development.  This  type  of  simulation-based  design  (SBD)  can  be 
used  to  develop  the  tools  that  the  military  will  need  to  transition  to  the  next  century.  This  thesis 
presents  solutions  to  previously  unsolved  underwater  robot  challenges,  new  capabilities  in  mine 
warfare  and  advancements  in  SBD  techniques. 

1.         Mine  Warfare 

The  NPS  AUV  research  group  has  been  striving  with  great  success  to  provide  a  low-cost  robot 
solution  to  mine  detection  and  classification  since  1986.  The  next  logical  step  is  to  provide  a  sound 
method  for  the  forward  deployment  and  retrieval  of  AUV  technology.  Demonstrating  that  an  AUV 
can  be  released  and  recovered  underway  "closes  the  loop"  for  AUVs  by  providing  fully  deployable 
technological  solutions. 
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Submerged  vehicle  launch  has  a  relatively  easy  solution.  Submarines  have  been  launching 
various  objects  through  torpedo  tubes  since  World  War  I.  While  some  modifications  to  existing  tube 
hardware  may  be  required,  a  clear  path  to  the  launching  solution  exists.  The  most  difficult  problem 
for  submarine  deployment  is  recovery.  Recovery  is  essential  for  mission  data  analysis  and  AUV  re- 
use.     This  work  provides  an  important  missing  link:  autonomous  vehicle  control  through  turbulent 
water  flow  while  docking.  This  new  capability  provides  submarines  the  potential  to  effectively  engage 
in  counter  mine  warfare  through  deployment  of  recoverable  AUVs. 

2.  Platform  Independence 

A  second  motivation  for  this  research  is  commonly  referred  to  (in  the  computer  science 
domain)  as  platform  independence.  In  the  context  of  the  problem  at  hand  it  is  taken  to  mean  providing 
the  ability  to  simulate  complex  virtual  environments  on  whatever  computer  resources  are  available, 
regardless  of  make,  architecture,  or  operating  system.  As  computational  power  has  increased  in  the 
recent  past,  complex  simulations  are  no  longer  limited  to  users  with  high-end  graphics  workstations. 
Personal  computers  have  the  capacity  to  manage  applications  that  were  previously  unavailable. 

The  vision  this  work  has  pursued  is  one  in  which  anyone  anywhere  with  network  connectivity 
can  view  and  actively  participate  in  complex  simulation  exercises.  We  are  attempting  to  build  a  closer 
link  between  those  involved  in  design  and  testing  and  the  end  user  of  technology.  While  the  platform- 
independence  issue  is  not  directly  related  to  solving  torpedo  tube  docking  of  an  AUV,  its  importance 
cannot  be  underestimated.  It  drives  home  the  point  that  simulation  for  spatial  awareness  can  be  used 
anywhere. 

C.       OBJECTIVES 

The  objective  of  this  research  is  to  design  a  method  of  simulating  AUV  control  in  a  true  ocean 
environment  in  order  to  accurately  test  and  develop  algorithms  for  moving  torpedo  tube  recovery.  To 
achieve  this  goal  there  are  several  sub-problems  to  address: 

►  Wave  motion  must  be  accurately  simulated  for  numerous  sea  states.  This  is  significant 
due  to  the  unpredictability  of  the  ocean  environment.  For  a  prototype  AUV  to  be  fully 
tested,  all  possible  sea  conditions  must  be  available. 

►  Foreign-body-induced  flow  forces  must  be  depicted  as  realistically  as  currently 

-3- 


possible.  These  types  of  forces  pose  the  most  difficult  problems  to  the  development  of 
control  algorithms  for  several  reasons.  First,  they  are  extremely  dynamic.  The  state  of 
flow  forces  are  continuously  changing  and  influenced  by  many  independent  factors, 
many  of  which  are  not  yet  completely  understood.  Second,  they  occur  in  the  regions 
where  robot  control  is  most  crucial,  i.e.  the  areas  where  a  control  failure  could  cause 
devastating  damage  to  both  the  robot  and  recovery  vehicle. 

Extensibility  needs  to  be  considered  when  modeling  flow  fields.  While  a  significant 
amount  is  known  about  the  nature  and  behavior  of  complex  fluid  flow,  there  is  still 
much  to  be  discovered.  By  creating  a  methodology  which  allows  for  the  upgrade  of 
simulation  flow  field  data  as  the  science  of  fluid  dynamics  advances,  the  accuracy  and 
lifetime  of  the  virtual  world  is  enhanced. 

Refinement  of  the  equations  of  motion  is  also  necessary.  The  ability  to  model  a 
vehicles  behavior  based  on  its  size  and  shape  as  forces  act  upon  it  becomes  another 
concern  when  trying  to  ensure  the  behavioral  accuracy  of  such  an  environment.  In 
previous  versions  of  the  Phoenix  AUV's  Virtual  World  the  equations  of  motion  were 
based  solely  on  a  cylindrical  body  shape. 

The  source  code  for  the  Phoenix  AUV  Virtual  World  is  distributed  openly. 
Unfortunately,  due  to  the  computational  complexity  of  such  a  model  its  use  has 
previously  been  feasible  for  only  those  users  with  high-end  Silicon  Graphics 
workstations.  With  the  capabilities  of  personal  computers  rapidly  increasing  and  the 
introduction  of  platform-independent  languages  (such  as  Virtual  Reality  Modeling 
Language  (VRML)  and  Java)  it  has  become  possible  to  move  this  simulation  into  the 
platform-independent  domain.  To  this  end  a  platform-independent  implementation  is 
also  provided. 


D.        THESIS  OUTLINE 

This  chapter  describes  the  background,  motivation,  and  objectives  of  creating  a  virtual  world 
which  accurately  models  the  ocean  environment.  Chapter  U  discusses  the  background  of  the 
Autonomous  Underwater  Vehicle  (AUV)  at  the  Naval  Postgraduate  School  (NPS)  including  its 
purpose,  history  and  related  research  projects.  Chapter  HJ  evaluates  the  goals  of  this  work  providing  a 
clear  and  concise  problem  statement.  Chapter  IV  provides  in-depth  discussion  of  design 
considerations  and  hydrodynamics  modeling  related  to  the  simulation.  Chapter  V  addresses  changes 
required  to  the  AUV  execution  level,  both  hardware  and  software,  needed  to  equip  the  vehicle  so  it 
can  successfully  operate  in  such  an  environment.  Chapter  VI  and  Chapter  VII  describe  the  simulation 
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results  found  in  this  research,  including  run-time  performance,  simulation  limitations  and  robot 
control/sensor  upgrades.  Chapter  VEQ  presents  conclusions,  research  contributions  and 
recommendations  for  future  work. 


-5- 


-6- 


II.  RELATED  WORK 

A.  INTRODUCTION 

The  technology  involved  in  virtual  environment  development  and  robot  simulation 
encompasses  many  disciplines.  While  these  two  tasks  seem  to  be  well  suited  for  one  another,  the 
fields  of  study  that  produce  the  theories  employed  by  each  are  vastly  different.  This  chapter  looks  at 
the  important  areas  evaluated  for  use  in  this  research.  The  topics  range  from  cutting-edge  computer 
graphics  to  mechanical  engineering  practices  that  have  been  around  for  many  decades.  Nevertheless, 
all  of  these  techniques  are  needed  to  create  the  solution  to  this  difficult  problem. 

Specific  related-work  topics  examined  in  this  chapter  include  Phoenix  AUV  hardware  and 
software,  underwater  virtual  world  modeling,  distributed  control,  the  Virtual  Reality  Modeling 
Language  (VRML),  the  Java  programming  language,  the  Distributed  Interactive  Simulation  (DIS) 
protocol,  the  DIS-Java-VRML  project,  and  Computational  Fluid  Dynamics  (CFD). 

B.  PHOENIX  AUV 

An  Autonomous  Underwater  Vehicle  (AUV)  is  a  self-contained  underwater  robot  typically 
combining  a  multitude  of  sensors  and  controllers.  The  Phoenix  AUV  is  an  incarnation  of  this  type  of 
robot  developed  to  demonstrate  the  abilities  of  a  low-cost  autonomous  platform.  The  Phoenix 
architecture  can  be  broken  down  into  two  major  categories:  hardware  and  software. 

1.        Hardware  Architecture 

The  Naval  Postgraduate  School's  (NPS)  Phoenix  AUV  is  a  complex  robot,  comprised  of  a 
single  water-tight  compartment  which  contains  various  motors,  controllers,  servo-amplifiers,  and 
computers.  The  internal  component  layout  is  shown  in  Figure  2.1  .  Figure  2.2  shows  the  an  external 
view  of  the  hardware  layout. 

The  main  processing  power  inside  the  Phoenix  comes  from  two  computers.  A  Gespac  M68030 
is  used  to  run  the  execution  level  software  while  a  Sun  Voyager  Sparc  5  Workstation  runs  the  tactical 
and  strategic  level  software  (Brutzman,  1998).  The  specifics  of  each  software  level  will  be  discussed 
in  the  following  section.  The  Gespac  computer  runs  the  OS-9  operating  system  allowing  for  use  of 


real-time  multitasking  functions  when  controlling  the  vehicle  devices  (Byrnes,  1993).  The  Sun 
Voyager  5  runs  SunOS  5.4.  These  computers  are  networked  together  via  an  Ethernet  inside  the 
vehicle.  This  allows  for  the  machines  to  easily  communicate.  It  also  has  advantages  in  terms  of 
remote  monitoring.  The  Ethernet  optionally  provides  Internet  connectivity  to  the  boat  through  a 
tether.  The  tether  can  be  used  to  monitor  each  process,  collect  data,  or  to  intervene  when  an 
operational  fault  occurs. 
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Figure  2. 1 .  Internal  view  of  the  Phoenix  AUVs  component  layout 
(Marco,  1996).  -8- 


Other  interesting  pieces  of  gear  include  two  high-resolution  sonar  units,  a  Global  Positioning 
System,  and  an  inertial  navigation  package.  The  sonar  units  provide  excellent  detect  and  classification 
abilities.  They  have  1  cm  resolution  out  to  a  maximum  range  of  30  meters.  Additionally,  the  ST725 
(725  KHz)  has  a  1  °  wide  by  24°  vertical  beam,  and  the  ST  1000  (1  MHz)  a  conical  beam  of  1  ° 
(Brutzman  et  al,  1998).  All  of  these  devices  are  used  to  provide  a  fully  autonomous  robot  with 
significant  operational  and  navigational  capabilities. 
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Figure  2.2.  External  view  of  the  Phoenix  AUVs  component  layout  (Marco,  1996). 
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2.        Software  Architecture 

The  software  architecture  of  the  Phoenix  AUV  is  a  tri-level  design  called  the  Rational 
Behavior  Model  (RBM).  The  RBM  architecture  consists  of  three  separate  software  layers,  each  layer 
having  its  own  functional  requirements,  implementation  restrictions,  and  component  interfaces 
(Byrnes,  1993)(Byrnes,  1996)(Marco,  Healey,  McGhee,  1996).  RBM  divides  robot  control  into 
functional  blocks  which  mimic  those  of  a  submarine  operational  structure.  Thus  the  use  of  RBM  in 
the  NPS  vehicle  is  well  suited  to  the  thinking  patterns  of  students  involved  in  the  project. 

The  RBM  divides  responsibilities  into  areas  of  open-ended  strategic  planning,  soft  real-time 
tactical  concern,  and  hard  real-time  execution  level  tasks.  Figure  2.3  shows  the  relationship  between 
strategic,  tactical  and  execution  levels  in  the  RBM. 
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Figure  2.3.  The  Rational  Behavior  Model  Architecture  Pyramid  (Holden,  1995) 

The  execution  level  provides  the  interface  between  software  and  hardware.  It  is  designed  to 
meet  all  of  the  systems  hard  real-time  requirements.  The  execution  level  is  responsible  for  the 
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underlying  stability  of  the  vehicle,  the  control  of  individual  devices,  and  providing  data  to  the  tactical 
level  (Byrnes,  1993)(Byrnes,  1996).  In  terms  of  an  underway  watch  team  organization,  the  execution 
level  performs  the  tasks  normally  assigned  to  individual  watchstanders. 

The  level  of  command  above  the  watchstanders  in  the  underway  watch  team  is  the  Officer  Of 
the  Deck  (OOD).    The  OOD's  responsibilities  are  concerned  with  the  tactical  picture:  what  individual 
tasks  need  to  be  completed  to  reach  a  goal.  In  the  RBM  this  functionality  is  contained  in  the  tactical 
level.    The  tactical  level  does  not  operate  on  hard  real-time  deadlines,  rather  it  operates  in  terms  of 
discrete  events  (Byrnes,  1993)(Byrnes,  1996).  It  provides  a  software  level  that  interfaces  with  both  the 
execution  and  the  strategic  levels,  thus  giving  strategic  level  indication  of  vehicle  state  and  completed 
tasks,  and  execution  level  commands. 

The  highest  level  of  the  RBM  is  the  strategic  level.  This  portion  corresponds  to  the  role  of  a 
commanding  officer.  It  is  not  concerned  with  the  specifics  of  task  completion.  Instead  the  issues  that 
the  strategic  level  monitors  are  the  completion  of  mission  goals.  Inside  the  strategic  level  resides  the 
mission  specification.  Through  symbolic  computing  it  uses  a  set  of  rules  coupled  with  an  inference 
engine  to  direct  (and  respond  to)  the  tactical  level  (Byrnes,  1993)((Bymes,  1996). 

The  RBM  is  a  complex  architecture,  but  it  greatly  simplifies  AUV  design  and  operation 
through  appropriate  levels  of  abstraction.  By  setting  clear  boundaries  between  areas  of  responsibility, 
RBM  enables  robot  control  to  be  defined  by  separate  applications  with  predefined  interfaces.  RBM 
also  allows  naval  students,  who  are  intimately  familiar  with  an  at-sea  watch  structure,  to  apply  real- 
world  experience  to  complicated  control  problems.  Using  an  architecture  designed  for  both  robot  and 
human  requirements  has  been  a  crucial  advantage. 

C.       PHOENIX  AUV  VIRTUAL  ENVIRONMENT 

Development  of  an  AUV  poses  a  number  of  unique  problems.  Chief  among  those  problems  is 
the  fact  that  during  the  actual  in-water  testing  of  robot  hardware  and  software,  it  is  often  impossible  to 
observe  or  communicate  with  the  vehicle.  Analysis  is  typically  limited  to  post-exercise  data  review 
alone.  This  situation  confronts  designers  with  a  difficult  development  process.  Physical  remoteness 
and  inability  to  observe  effectively  takes  away  one  of  the  human  mind's  greatest  strengths:  the  ability 
to  visualize.  To  overcome  this  problem,  a  virtual  world  was  developed  which  models  salient 

-11- 


characteristics  of  the  ocean  environment  from  the  robot's  perspective  (Brutzman,  1994).  This 
effectively  puts  humans  back  into  middle  of  the  testing  and  development  loop,  and  allows  developers 
to  visualize  robot  behavior  under  diverse  conditions. 

The  virtual  environment  provides  an  area  of  underwater  terrain  in  which  testing  and 
development  can  be  observed.  Figure  2.4  is  a  recent  view  of  the  underwater  world  showing  all  of  the 
major  objects  that  are  contained,  including  Phoenix  at  the  surface  just  right  of  center.  The 
implementation  of  the  Phoenix  AUVs  virtual  world  is  broken  into  three  major  sections.  One  portion 
represents  the  physical  side  of  the  operating  environment,  a  second  is  robot  software  (and  optionally 
hardware),  and  a  third  provides  an  interactive3D  graphics  window  into  the  virtual  environment. 


Figure  2.4  -  The  Phoenix  AUV  Virtual  World. 
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The  most  complex  of  the  modules  which  comprise  the  virtual  environment  is  the  one  which 
models  the  vehicle  hydrodynamics.  Inside  this  program  all  aspects  of  vehicle  motion  are  considered. 
Using  a  Newton-Euler  approach  to  the  derivation  of  the  six  degree-of-freedom  equations  of  motion 
(Brutzman,  1994)(Healey,  1992),  the  program  provides  a  very  accurate  rendition  of  the  environment. 
The  dynamics  program  takes  input  from  the  vehicle,  describing  the  state  of  all  of  its  devices,  and 
calculates  in  complete  detail  the  responses  the  vehicle  is  expected  to  receive  from  the  environment. 
Other  physical  models  includereal-time  sonar  detection,  Global  Positioning  System  (GPS),  and 
acoustic  navigation. 

Another  component  of  the  virtual  environment  is  the  AUV  software.  This  code  performs  the 
task  of  controlling  all  of  the  devices  associated  with  the  AUV,  including  propellers,  thrusters,  sonars, 
inertial  navigation  systems  and  any  other  hardware  installed  on  Phoenix.  This  execution  level  control 
is  coupled  with  the  more  sophisticated  robot  intelligence  provided  by  the  strategic  and  tactical  levels. 
Communication  is  conducted  through  all  levels  of  the  RBM  architecture  to  determine  how  to  deploy 
each  one  of  these  devices.  After  determining  the  state  of  each  sensor  and  effector,  the  execution  level 
sends  out  the  commands  placing  them  in  the  appropriate  state.  Since  in  the  virtual  simulation  the 
devices  are  typically  not  physically  present,  they  are  positioned  via  telemetry  vector  message 
interchange  with  the  dynamics  program.  The  effects  of  all  the  devices  are  determined  by  the  dynamics 
program  models,  and  then  proper  responses  are  sent  back  to  the  execution  level  software.  This  query- 
response  interchange  is  incorporated  into  the  sense  and  act  phases  of  the  execution  level's  sense- 
decide-act  cycle.  This  design  architecture  enables  the  robot  to  run  and  respond  to  various  stimuli  in 
the  same  manner  in  the  virtual  world  as  in  the  real  world,  since  the  robot  software  in  each  case  is 
identical  (Burns,  1996). 

The  final  portion  of  the  virtual  environment  gives  the  user  an  interactive  3D  graphics  window 
into  the  environment.  Referred  to  as  the  viewer,  this  program  allows  observation  of  all  aspects  of  the 
simulation.  Virtual  representations  are  provided  to  indicate  the  robots  employment  of  each  sensor  and 
effector.  This  visualization  has  repeatedly  been  shown  to  be  essential  to  the  development  process. 
Figure  2.5  shows  the  animations  associated  with  the  robots  use  of  thrusters  and  propellers. 
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Figure  2.5.  Phoenix  AUV  in  the  virtual  environment 
demonstrating  use  of  thrusters  and  main  motors. 


This  type  of  visual  representation  also  gives  some  intuition  into  how  the  AUV  employs  its 
sonar  assets.  Sonar  visualization  was  used  to  implement  and  refine  a  control  algorithm  which  enables 
the  Phoenix  AUV  to  detect  and  classify  objects  in  the  water  (Davis,  1996).  In  the  case  of  a  detected 
tube  like  object  the  algorithm  was  further  enhanced  to  allow  the  vehicle  to  safely  begin  entering  the 
tube.  Figure  2.6  is  a  screen  capture  of  this  type  of  mission  being  executed  in  the  virtual  environment. 

All  of  these  components  are  networked  together  to  provide  an  integrated  development 
environment.  Multiple  simultaneous  viewers  are  enabled  via  use  of  the  Distributed  Interactive 
Simulation  (DIS)  protocol  (IEEE,  1993)(IEEE,  1994a)(IEEE,  1994b).  The  position,  orientation  and 
state  of  the  vehicle  are  multicast  across  the  network  via  Entity  State  Protocol  Data  Units  (ESPDU). 
The  viewer  application  listens  to  the  network  for  these  packets,  extracts  the  information  from  them, 
and  incorporates  it  into  the  scene  rendered  in  the  virtual  world.  Decoupling  graphics  viewers  from 
robot  software  and  virtual  world  models  provides  a  scalable  approach  that  permits  multiple 
researchers  to  evaluate  robot  mission  progress. 

The  versatility  of  the  virtual  world  was  further  demonstrated  by  its  use  for  prototype  modeling 
of  an  optical  sensor,  used  for  AUV  guidance  and  control  without  sonar,  while  docking  with  a 
stationary  torpedo  tube  (DelTheil,  1997). 
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Figure  2.6.  Phoenix  AUV  Using  Sonar  to  detect  and  Classify  a  Torpedo 
Tube  (Davis,  1996). 

A  virtual  environment  provides  an  outstanding  arena  for  robot  testing  and 
development.  It  affords  system  engineers  the  opportunity  to  observe  equipment  operation  in  a  safe 
controlled  environment.  This  type  of  technological  advance  is  a  large  step  forward  for  the  underwater 
robot  community. 

D.       DISTRIBUTED  ANALOG/DIGITAL  CONTROL  DEVELOPMENT 

Computing  power  has  been  increasing  at  an  amazing  rate.  The  average  lifetime  for  new 
technology  in  the  computer  industry  is  only  nine  months,  with  processing  power  increasing  by  an 
order  of  magnitude  every  two  years.  One  area  in  which  similar  advances  are  being  made  is 
networking.  These  advances  have  come  in  transfer  rate  increases  and  reliability  improvements.  This 
allows  system  designers  to  leverage  the  network  (and  all  the  resources  attached  to  it)  as  additional 
assets. 

The  network  provides  an  unlimited  number  of  additional  resources  to  any  computing  system. 
Similar  advances  are  also  being  made  in  control  technology  for  data  acquisition  systems.  Smart 
controllers  present  the  opportunity  to  create  autonomous  device  controls  which  can  monitor  device 
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operation,  output  necessary  data  readings,  and  react  properly  when  provided  operational  commands 
from  remote  stations.  One  company  leading  the  way  in  this  field  is  Echelon.  They  have  developed  a 
series  of  programmable  devices  which  all  communicate  over  a  network  using  a  proprietary  network 
protocol  called  LonTalk  (Young,  1998). 

Use  of  small  specialized  processors  can  give  any  system  significant  performance 
improvements.  By  offloading  portions  of  specialized  control  code  a  central  monitor  application 
becomes  more  concise,  allowing  it  to  execute  more  quickly  and  efficiently.  It  also  adds  to  system 
robustness.  No  longer  will  a  single  fault  halt  operation.  Other  devices  not  affected  by  a  single  control 
board  failure  will  continue  to  operate  normally,  leaving  the  monitoring  application  to  adjust  for  a 
single  device  failure. 

Distributed  control  is  the  direction  in  which  many  data  acquisition  systems  are  moving. 
Systems  as  diverse  as  elevator  control  systems  and  high-voltage  air  conditioning  systems  all  gain 
from  distributed  control.  This  technology  can  also  give  the  Phoenix  AUV  execution  level  a  welcome 
upgrade  (Young,  1998). 

E.       VIRTUAL  REALITY  MODELING  LANGUAGE  (VRML) 

As  the  Internet  continues  to  expand  and  gain  in  popularity,  many  new  technologies  are  being 
developed  to  utilize  this  medium.  In  the  past,  browsing  web  pages  has  been  restricted  to  two 
dimensions.  The  Virtual  Reality  Modeling  Language  (VRML)  brings  three-space  to  the  Web. 

VRML  is  an  interpreted  language  that  allows  developers  to  create  content-rich  three- 
dimensional  (3D)  worlds  which  can  be  viewed  across  the  Internet  inside  a  web  browser.  At  its  core 
VRML  is  a  specification  for  describing  3D  worlds  through  a  text-based  file  format  (Ames, 
1997)(VRML,  1997). 
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#VRML 

V2  . 0  utf8 

Group 

{ 

Children 

Viewpoint    { 

description     Initial  view 

position           6-10 

orientation     0  1  0  1.57 

} 
Shape  { 

geometry  Sphere  {    radius  1  } 

appearance  Appearance  { 

texture  ImageTexture  { 

url     earth- topo .png 

}   }   > 

Transform    { 

translation    0  -2  1.25 

rotation      0  10       1.57 

Children  [ 

Shape  { 

geometry  Text  { 

} 

string  ["  Hello"  "world!"] 

appearance  Appearance  { 

material  Material  { 

diffuseColor  0.1   0.5   1 

} 
] 
} 

}}} 

] 

Figure  2.7.  VRML  source  code  hello_world.wri  taken  from  (Brutzman, 
1998a). 

While  VRML  is  a  powerful  object  description  language,  it  is  also  a  simple  language  to  learn. 
The  novice  can  quickly  learn  enough  to  develop  his  first  program.  Figure  2.7  is  a  programming  listing 
for  the  basic  "Hello  World"  program  found  in  so  many  programming  texts  (Brutzman,  1998a).  The 
results  of  this  small  scene  description  are  displayed  in  Figure  2.8.  This  demonstrates  just  how  simple 
VRML  makes  3D  authoring. 
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Figure  2.8.  Output  of  Hello_world.wri. 

The  power  of  VRML  is  its  ability  to  create  dynamic  environments.  It  fully  supports  animation, 
user  interaction,  and  advanced  object  behaviors  through  scripts  (Hartman,  1997).  After  describing 
objects  inside  a  world  a  developer  has  many  options  regarding  how  to  use  those  objects.  Animation 
can  be  performed  through  predetermined  routes,  execution  of  scripts,  or  dynamically  using  outside 
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applications  to  manipulate  objects  inside  the  world.  The  overall  affect  is  the  creation  of  portable 
virtual  environments  which  are  visually  pleasing  and  truly  interesting.  The  greatest  promise  of  VRML 
with  respect  to  this  project  is  the  possibility  of  3D  visualization  of  AUV  missions  using  any  web 
browser. 

F.         JAVA 

Java  is  a  fully  functional  programming  language  which  was  first  released  in  1995  by  Sun 
Microsystems.  It  is  a  solidly  engineered  language  that  was  created  with  many  ideal  design  goals  in 
mind.  Table  2.1  gives  the  key  features  as  described  by  the  authors  of  Java  (Cornell,  1997).  The  key 
features  of  interest  related  to  the  work  described  in  this  thesis  are  that  it  is  architecture  neutral,  object 
oriented,  and  portable  (Cornell,  1997). 

Java  is  an  architecture-neutral  language.  What  this  means  is  that  when  a  Java  program  is 
compiled  the  compiler  creates  a  neutral  file  format  that  contains  byte  codes  of  the  compiled  program. 
These  byte  codes  can  then  be  executed  on  many  different  processors  with  the  Java  run-time 
environment  present.  The  run-time  system  interprets  the  byte  codes  and  translates  the  information  into 
native  machine  code  for  execution. 


Java  Design  Goals 

Functionality  of  Concern  for  this  Thesis 

Simple 

Yes 

Object-Oriented 

Yes 

Distributed 

No 

Robust 

No 

Secure 

No 

Architecture  Neutral 

Yes 

Portable 

Yes 

Interpreted 

No 

High  Performance 

Yes 

Multithreaded 

No 

19- 


Dynamic 

No 

Table  2.1.  Design  goals  of  the  Java  programming  language,  contrasted  with  thesis  goals. 

The  object-oriented  programming  paradigm  provides  numerous  useful  characteristics.  Java 
fully  supports  data  hiding,  encapsulation,  inheritance  and  code  reuse  through  this  object-oriented 
approach.  This  type  paradigm  focuses  on  the  data  being  manipulated  by  an  application  instead  of  how 
each  step  of  the  manipulation  takes  place.  It  gives  the  developer  the  ability  to  write  code  once  and  use 
it  many  times  in  many  different  applications. 

Portability  brings  Java  to  the  Web.  There  are  no  implementation-dependent  aspects  of  the  Java 
specification  (Cornell,  1997).  This  means  that  the  binary  data  is  stored  in  a  fixed  format  which 
eliminates  the  problems  of  running  code  on  various  platforms.  Through  this  type  of  implementation 
and  the  use  of  standard  libraries  which  define  portable  interfaces,  Java  byte  codes  can  be  retrieved 
across  the  Internet  and  run  on  local  platforms,  independent  of  the  machine  architecture. 

As  the  world  wide  web  continues  to  increase  in  popularity,  Java  is  positioned  to  be  the 
language  of  choice.  Its  well-designed  class  library  provides  all  the  functionality  required  to  develop 
professional  applications.  These  applications  can  be  easily  distributed  via  the  Internet  and  run  on  any 
platform  which  has  the  Java  run-time  environment  present. 

G.       DISTRIBUTED  INTERACTIVE  SIMULATION  (DIS)  PROTOCOL 

The  Distributed  Interactive  Simulation  (DIS)  protocol  describes  a  standard  of  communications 
between  entities  in  distributed  simulations  (IEEE  93,  94a,  94b).  It  is  well  suited  for  general  usage  in 
networked  virtual  environments  due  to  the  standardization  of  object  interactions.  This  allows  many 
users  in  remote  locations  to  view  or  participate  in  a  simulation  as  long  as  the  standard  object  interface 
is  followed. 

Information  is  passed  between  entities  through  the  use  of  protocol  data  units  (PDUs).  Figure 
2.9  demonstrates  the  architecture  of  a  distributed  simulation  using  DIS.  There  are  27  different  types  of 
PDUs  defined  for  use.  Each  one  addresses  a  different  possible  interaction  between  entities.  Types  of 
PDUs  range  from  the  most  common  Entity  State  PDU,  to  the  more  rarely  used  Electromagnetic 
Emission  PDU.  The  Entity  State  PDU  is  the  primary  PDU  used,  containing  information  about  an 
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entity's  position,  posture,  linear  and  angular  velocities  and  accelerations.  It  is  sent  across  the  network 
by  an  object  whenever  one  of  the  its  entity  state  parameters  changes  by  a  threshold  amount  or  a 
designated  time  period  has  expired.  All  other  entities  that  are  concerned  with  the  position  information 
of  the  sending  entity  will  listen  for  the  PDU  and  upon  receipt  will  integrate  that  information  into  the 
rendered  scene. 

Networking  provides  a  significant  advantage  when  working  in  virtual  environments.  It  allows 
objects  which  are  being  operated  on  remote  workstations  to  be  viewed  locally.  In  a  complex  world 
objects  can  be  offloaded  to  idle  processors  while  they  are  rendered  by  the  local  machine.  This  type  of 
network  interaction  is  possible  through  the  standards  defined  by  the  DIS  protocol. 


Simulation  1       Simulation  2       Simulation  3 


Network 


Figure  2.9.  Network  Connectivity  of  a  DIS  simulation. 

H.       DIS-JAVA-VRML 

In  an  effort  to  bring  large-scale  distributed  simulations  to  the  personal  computer  domain  a 
working  group  has  been  formed  to  integrate  DIS  with  Java  and  VRML.  A  VRML  Consortium 
(www.vrml.org")  working  group  is  a  technical  committee  which  tries  to  solve  specific  technical 
problems.  The  DIS-Java-VRML  working  group  was  chartered  with  numerous  goals  aimed  at  making 
these  technologies  work  together. 
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Some  specific  objectives  of  the  DIS-Java-VRML  working  group  include  completing  a  freely 
available  Java  implementation  of  the  DIS  protocol,  producing  a  set  of  references  and  recommended 
practices  for  mapping  between  DIS  and  VRML  worlds,  create  various  DIS  utilities  in  Java,  and  to 
also  create  some  standard  physics  and  math  libraries  to  be  used  in  these  simulations.  More 
information  for  regarding  the  working  group  can  be  found  at  fhttp://www. stl.nps.navy.mil/dis-java- 
vrml  1. 
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Figure  2.10.  DIS-Java-VRML  interaction  layout. 


The  overall  layout  of  a  simulation  using  the  DIS-Java-VRML  library  is  quite  unique.  The 
library  handles  the  interactions  between  the  network,  browser,  and  VRML  plugin.  Figure  2.10 
outlines  the  interactions  handled  by  the  library. 

Combining  the  capabilities  of  DIS,  Java  and  VRML  can  quickly  allow  developers  to  create 
content-rich  networked  simulations  that  are  available  to  anyone  with  access  to  the  Internet.  The 
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possibilities  of  simulation  content  and  complexity  are  endless.  With  access  via  the  Web  simulations 
can  be  run  anywhere  in  the  world  regardless  of  the  locality  of  participants  and  simulation  monitors. 
This  integration  truly  adds  new  dimensions  to  virtual  environment  use.  It  continues  to  move  the  Web 
into  three-space. 

I.        COMPUTATIONAL  FLUID  DYNAMICS  (CFD) 

Computational  Fluid  Dynamics  (CFD)  is  a  field  of  study  concerned  with  the  prediction  of 
fluid  motion  about  bodies  of  arbitrary  shape.  Supercomputers  are  typically  used  to  solve  numeric 
approximations  that  describe  the  fluid  flow. 

Looking  more  closely  at  the  term  CFD,  this  branch  of  science  is  considered  computational 
because  of  the  use  of  high-speed  computing  resources.  The  fluid  flows  are  typically  modeled  and 
analyzed  using  large  sets  of  Navier-Stokes  partial  differential  equations.  Solving  these  equations  for 
specific  fluid-flow  cases  is  computationally  intense  because  no  closed-form  solutions  exist,  except  in 
trivially  special  cases  (Scientific  Computing  Group  at  Indiana  University,  1998).  Thus  any  given 
problem  may  take  days  of  computational  cycles  to  solve.  Solution  of  CFD  problems  are  generally 
considered  to  be  among  the  grand  challenges  of  supercomputing. 

CFD  also  refers  to  the  analysis  of  fluids.  Fluid  refers  to  anything  that  isn't  a  solid,  thus  both 
air  and  water  are  considered.  A  more  technical  definition  classifies  fluids  "as  any  substance  which 
cannot  remain  at  rest  under  a  sliding,  or  shearing,  stress  (Scientific  Computing  Group  at  Indiana 
University,  1998)." 

Finally,  CFD  dynamics  refers  to  the  study  of  objects  in  motion.  In  dynamics  one  is  concerned 
with  an  objects  motion  and  the  forces  associated  with  that  motion.  This  is  very  different  from 
kinematics,  which  is  concerned  with  the  relationships  of  motion  quantities  regardless  of  the  forces 
induced  by  that  motion  (Healey,  1998).  Kinematics  models  are  typically  less  realistic  than  dynamics 
models.  In  general  the  resolution  of  kinematics  models  are  demonstrably  inadequate  for  AUV  motion 
prediction. 

Overall,  CFD  is  a  numerically  intensive  science.  Solutions  to  CFD  problems  are  extremely 
complex  and  often  require  the  most  advanced  computer  systems  to  solve.  Thus  research  in  this  field  is 
extremely  important,  providing  the  basis  for  understanding  complex  flow  interactions.  From  there 
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simpler  representations  of  flow  interactions  can  be  created  which  provide  a  general  model  for  testing. 
The  approach  taken  by  this  thesis  completely  avoids  the  field  of  supercomputing  CFD,  and  instead 
seeks  PC-based  or  workstation-based  solutions  which  produce  imperfect  but  adequate  results  in 
realtime  for  human  operator  and  robot  use. 

J.        SUMMARY 

Many  disciplines  are  needed  to  complete  any  complex  project.  The  basis  for  the  solution  to  the 
problem  of  torpedo  tube  docking  of  the  Phoenix  AUV  epitomizes  that  notion.  Simulation-based 
research  and  design  draws  from  the  newest  available  technologies.  While  the  environmental  forces 
which  must  be  modeled  in  this  type  of  simulation  have  been  around  since  the  beginning  of  time,  only 
recently  has  technology  been  created  to  help  man  solve  problems  in  many  disciplines.  A  broad  level 
of  knowledge  must  be  used  to  arrive  at  a  correct  solution  when  considering  large  and  complex 
problems. 

This  chapter  presented  an  overview  of  many  topics  related  to  the  solutions  presented  in  this 
thesis.  The  Phoenix  AUV  hardware,  software  and  underwater  virtual  world  modeling  were  discussed 
because  they  provide  the  basis  for  the  testing  presented.  Other  areas  such  as  distributed  control,  the 
Virtual  Reality  Modeling  Language  (VRML),  the  Java  programming  language,  the  Distributed 
Interactive  Simulation  (DIS)  protocol,  the  DIS-Java-VRML  project  and  Computational  Fluid 
Dynamics  (CFD)  also  play  a  role  important  roles  in  solving  the  problem  of  torpedo  tube  recovery. 
While  no  one  topic  provides  all  answers,  a  combination  provides  a  well-rounded  solution. 
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III.  PROBLEM  STATEMENT 

As  the  mission  of  the  United  States  Navy  continues  to  focus  on  littoral  warfare,  the 
importance  of  mine  warfare  becomes  more  apparent.  Mine  warfare  has  historically  been  one  of  the 
most  difficult  tasks  performed  by  naval  units.  The  majority  of  the  tactical  burden  has  often  fallen  on 
submarines  since  their  operational  areas  often  coincide  with  the  areas  of  most  value  to  enemy  forces. 
One  outstanding  tool  for  mine  detection  is  an  Autonomous  Underwater  Vehicle  (AUV).  This  type  of 
robot  can  be  used  to  scour  forward  areas  using  high-frequency  sonars  and  global  positioning  systems 
(GPS)  to  detect  and  neutralize  mines,  easing  the  burden  of  mine  detection  on  all  forward-deployed 
units. 

The  majority  of  technical  issues  preventing  this  type  of  AUV  deployment  have  been  solved. 
The  only  problem  remaining  before  this  type  of  vehicle  deployment  can  be  executed  is  the  vehicle 
recovery  system.  Vehicle  recovery  poses  many  difficult  problems.  The  evolution  itself  is  very 
dangerous  for  both  the  recovering  submarine  and  the  AUV.  Even  the  smallest  mistake  can  place  the 
submarine  at  great  risk.  If  the  recovery  does  not  run  smoothly,  damage  can  range  from  complete  loss 
of  the  AUV  to  a  breach  of  the  water-tight  integrity  of  the  recovering  submarine,  thus  threatening  the 
safety  of  her  crew.  There  is  an  intolerably  small  margin  of  error. 

In  an  effort  to  conquer  the  unresolved  issues  associated  with  mine  warfare,  the  Phoenix  AUV 
has  been  created  as  a  research  and  development  platform.  It  is  used  to  test  the  newest  equipment  on 
the  market  and  to  develop  control  algorithms  which  employs  this  equipment  most  effectively.  Even  in 
stand-alone  development  the  risk  of  vehicle  loss  is  very  high.  While  robot  code  is  written  with  safety 
of  the  vehicle  in  mind,  robot  testing  is  inherently  dangerous.  For  that  reason  a  virtual  environment 
was  created  that  is  used  to  test  software  and  hardware  prior  to  in-water  testing  (Brutzman,  1994). 

A  virtual  world  provides  an  exceptional  resource  for  the  testing  and  development  of  AUV 
technology.  The  difficulties  associated  with  the  underwater  environment  are  numerous  and  complex. 
In  order  to  properly  validate  the  results  from  such  a  world,  one  must  accurately  model  the  physics 
associated  with  the  vehicle,  its  submerged  hydrodynamics  characteristics,  and  the  environment. 
Environmental  effects  such  wave  motion,  currents,  and  flow  forces  created  by  bodies  moving 
through  the  water  can  cause  significant  variance  in  the  testing  environment.  The  current  version  of 
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the  Phoenix  AUV  Virtual  World  includes  steady-state  ocean  currents,  but  does  not  take  into  account 
the  localized  environmental  effects  of  waves  and  body-induced  flow  forces. 

In  an  effort  to  provide  this  type  of  realistic  simulation  environment,  the  effects  of 
environmental  factors  have  been  completely  integrated  into  the  hydrodynamic  simulation.  This  work 
provides  a  sound  real-time  simulation  of  these  complex  factors  using  physically  based  models.  The 
problem  is  broken  down  into  wave  motion  effects,  body-induced  flow  fields,  and  AUV  motion 
control.  Each  one  is  thoroughly  analyzed  and  realistically  simulated  in  real-time  through  the 
algorithms  developed. 

The  result  of  this  research  is  a  Virtual  World  which  accurately  depicts  the  ocean  environment. 
It  can  be  used  to  test  and  develop  the  control  algorithms  required  to  operate  an  Autonomous 
Underwater  Vehicle  in  any  situation  without  risk.  This  environment  thus  provides  a  safe  and 
physically  accurate  arena  in  which  the  problem  of  torpedo  tube  recovery  can  be  carefully  examined. 

Another  issue  evaluated  in  this  work  is  platform  independence.  As  research  and  development 
money  becomes  scarce,  the  availability  of  high-end  graphics  workstations  is  also  becoming  rare.  With 
the  advent  of  platform  independent  languages  such  as  Virtual  Reality  Modeling  Language  (VRML) 
and  Java,  the  ability  to  run  complex  three-dimensional  (3D)  simulations  on  personal  computers  has 
arrived.  In  addition  to  providing  a  realistic  virtual  environment  for  development  of  new  technology 
this  work  strives  to  make  that  simulation  available  for  anyone  to  use.  By  using  web-based 
technologies  anyone  can  view  and  interact  with  the  simulation  and  development  process,  further 
advancing  the  marriage  between  developer  and  end  user. 

The  principal  problem  addressed  by  this  thesis  is  that  of  torpedo  tube  recovery  of  the  Phoenix 
AUV.  It  employs  a  physically  based  virtual  environment  to  simulate  the  forces  encountered  during 
such  an  evolution.  The  goal  is  to  provide  an  overall  solution  to  the  problems  associated  with  torpedo 
tube  recovery  through  simulation-based  design  (SBD). 
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IV.  HYDRODYNAMICS  MODELING 

A.  INTRODUCTION 

This  chapter  presents  the  theory  behind  the  implementation  of  cross-body  flow  in  the  Phoenix 
virtual  environment.  The  problem  of  modeling  cross-body  flow  is  broken  down  into  several 
components,  each  of  which  is  analyzed  in  depth.  An  overview  first  outlines  the  components  of  the 
equations  of  motion  algorithms  with  some  detail  on  the  individual  parts.  The  high-resolution 
buoyancy  model  is  described  as  the  basis  for  modeling  flow  forces  on  the  AUV.  Wave-motion 
simulation  is  examined  in  detail,  followed  by  body-induced  flow  simulation  and  square  hull  versus 
round  hull  adjustments  to  the  equations  of  motion. 

B.  OVERVIEW 

Virtual  environments  are  a  very  useful  tool  in  the  research  and  development  process.  Their  use 
can  provide  sound  simulation-based  designs.  The  ability  to  test  and  redesign  during  development 
allows  for  relatively  easy  correction  of  design  flaws  and  can  save  valuable  time  and  money  in  the 
process.  Nevertheless  any  simulation  is  only  as  good  as  the  physical  model  it  is  based  on.  A  virtual 
ocean  environment  which  fails  to  address  the  physical  forces  that  are  present  in  the  real  ocean 
provides  little  insight  during  development,  perhaps  guaranteeing  the  failure  of  the  project. 

The  elements  of  nature  must  be  completely  integrated  into  any  simulation  environment  if  it  is 
to  be  used  as  a  true  test  platform.  Additionally,  the  ocean  environment  has  unique  characteristics 
which  make  its  simulation  more  complex.  Factors  such  as  buoyancy,  wave  motion,  and  body-induced 
flow  forces  are  among  the  most  computationally  complex  to  model.  They  are  all  significant  and 
cannot  be  overlooked  when  developing  a  true  simulation  environment.  Figure  4. 1  shows  the  overall 
flow  of  information  within  the  hydrodynamics  model.  The  separate  sections  indicate  areas  of  code 
that  handle  specific  calculations  which  are  calculated  during  each  time  step.  The  overall 
hydrodynamics  model  is  described  in  (Brutzman  94a,  94b,  98).  The  simple  buoyancy  model  is 
described  in  (Bacon,  96).  This  thesis  implements  the  shaded  blocks  in  Figure  4.1.  Throughout  the 
following  discussion  of  theoretical  basis,  simplifications  were  made  to  ensure  true  real-time 
performance  of  the  simulation.  Assumptions  are  made  when  the  effect  of  their  simplification  do  not 
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effect  the  accuracy  of  the  model,  while  providing  performance  improvement.  Table  4. 1  provides  a 
summary  of  assumptions  which  will  be  presented  and  justified  later  in  the  chapter.  This  chapter 
provides  the  theoretical  basis  for  a  high-resolution  buoyancy  model,  physically  based  wave  motion 
simulation,  external  submarine  body-induced  flow  field  simulation,  more  precise  modeling  of  square 
hulls  versus  round  hulls,  and  refinements  to  the  equations  of  motion  (EOM). 


Topic 

Assumptions 

Wave  motion  simulation 

1 .  Wave  motion  effects  vehicle  position  and  orientation  are  due  to 
the  movement  of  water  across  the  vehicle  body  as  waves  move  past. 

2.  The  length  of  the  Phoenix  AUV  is  small  enough  that  measuring 
wave  height  above  the  vehicle  at  Vz  foot  increments  gives  a  realistic 
representation  of  the  wave  forces  felt  by  the  vehicle. 

Environmental  Factors 

1.  The  effects  of  ocean  current  are  felt  by  both  the  AUV  and  the 
submarine,  thus  the  relative  motion  caused  by  steady-state  current 
can  be  ignored  locally. 

2.  The  time  variation  of  environmental  factors  such  as  change  in  sea 
state  is  slow  and  can  be  ignored  for  the  duration  of  a  docking 
evolution. 

AUV  docking  approach 

1 .  The  AUV  will  always  approach  the  submarines  torpedo  tube  from 
aft  in  order  to  maintain  stability  and  minimize  risk  of  collision. 

2.  The  AUV  approach  course  will  be  such  that  it  never  passes 
through  the  turbulence  caused  by  the  submarines  propeller(s). 

Flat-plate  fluid  flow  theory 

1 .  The  submarine  is  large  enough  (when  viewed  from  the  AUV)  that 
the  hull  appears  as  a  flat  plate. 

2.  The  majority  of  drag  across  the  submarine  as  it  moves  through  the 
water  is  pressure  drag  vice  skin  friction  drag. 

Table  4.1.  Overview  of  assumptions  made  to  implement  wave  motion  and  flow  models. 
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} 
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1  Integration  of  Equations  of  Motion. 

Figure  4. 1 .  Flow  of  information  within  hydrodynamic  model  of  the  Phoenix  AUV 
virtual  environment. 


C.       BUOYANCY  MODEL 

Simulation  of  ocean-going  vehicles  poses  many  unique  problems.  They  differ  from  land- 
based  vehicles  by  exhibiting  six  degrees  of  freedom  (DOF)  in  their  movement.  They  primarily  differ 
from  air  vehicles  (which  do  move  in  six  degrees)  with  respect  to  buoyancy  forces.  Buoyancy  forces 
differ  significantly  from  the  lift  experienced  in  air  vehicles.  One  major  difference  between  these  types 
of  forces  in  the  modeling  and  simulation  context  is  fairly  straight  forward:  for  an  air  vehicle,  once  the 
dimensions  are  known,  the  lift  force  exerted  on  the  plane  is  proportional  to  air  speed.  From  these 
forces  one  can  easily  calculate  position  and  orientation.  In  the  sea-going  vehicle  domain,  however  the 
dynamics  model  isn't  as  simple.  Vehicle  buoyancy  is  a  major  contributor  to  determining  vehicle 
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position  and  orientation,  and  this  quantity  is  truly  dynamic  when  at  the  surface.  Buoyancy  varies 
based  on  the  amount  of  water  displaced  at  that  particular  time  step,  which  is  an  instantly  changing 
irregular  3D  volumetric  integral.  Therefore,  in  order  to  maintain  real-time  response,  the  calculation 
must  be  optimized  and  flexible.  This  is  especially  important  in  the  underwater  domain  since  buoyancy 
determines  whether  the  vehicle  can  maintain  depth  or  sink. 

The  original  virtual  world  hydrodynamics  model  only  handled  neutrally  buoyant  vehicles 
(Brutzman,  1994).  A  later  refinement  estimated  buoyancy  using  box  approximations  for  volume  and 
center  of  buoyancy  (Bacon,  1995).  This  approach  provided  reasonably  accurate  simulation  when  fully 
or  partially  submerged,  but  may  be  insufficient  when  the  submersible  is  continuously  operating  on  the 
surface  or  at  shallow  depths  in  a  surf  zone.  In  this  thesis,  a  high-resolution  model  is  presented  that 
precisely  approximates  volume  and  center  of  buoyancy  by  evaluating  the  submersible  over  1 5 
separate  slices.  Each  slice  has  its  own  buoyancy  (and  center  of  buoyancy)  that  are  approximated  and 
calculated  every  time  step.  Figure  4.2  shows  this  type  of  partitioning  applied  to  the  Phoenix  AUV. 


Figure  4.2.  AUV  broken  into  buoyancy  model  slices. 

This  buoyancy  model  works  well  and  accurately  models  vehicle  response  in  a  variety  of 
surfaced  and  broached  conditions.  When  submerged,  each  piece  of  the  AUV  retains  its  full  buoyant 
force  giving  the  AUV  neutral  buoyancy.  On  the  surface,  the  portions  of  the  boat  which  are  out  of  the 


-30- 


water  are  subtracted  from  the  net  buoyancy  giving  an  approximately  correct  value  for  that  condition. 
Additional  impacts  of  buoyancy  on  a  shifted  center  of  buoyancy  are  calculated  piecewise  and  then 
summed,  using  the  same  computational  model  provided  in  (Bacon,  1996).  Figure  4.3  graphically 
represents  the  buoyancy  model  from  (Bacon,  1996). 


Righting  Moment 


Original  CB 


Figure  4.3.  Effect  of  submerged  body  exiting  water  on  center  of  buoyancy  (Bacon, 
1996) 


The  only  condition  not  considered  previously  was  the  effect  of  ocean  waves  on  vehicle 
buoyancy.  Since  the  model  worked  so  well  for  the  boundary  conditions  it  seemed  appropriate  to 
extend  it  by  adding  the  needed  functionality  to  accurately  model  sea  state  effects  on  vehicle  motion. 
In  order  to  do  so  there  are  several  factors  to  consider  and  assumptions  to  make.  Issues  to  address 
range  from  what  forces  are  that  wave  motion  produces,  how  these  can  be  estimated,  and  finally  how 
are  they  applied  to  the  vehicle  to  produce  an  accurate  simulation. 

The  first  assumption  to  be  evaluated  applies  to  the  effect  wave  motion  has  on  the  vehicle 
itself.  In  other  words,  how  do  the  forces  created  by  passing  waves  cause  the  position  and  orientation 
of  the  AUV  to  change?  When  discussing  underwater  hydrodynamics  one  often  arrives  at  the  effects 
on  a  submerged  body  by  multiplying  the  flow  which  is  present  across  the  body  via  cross-body  drag 
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calculations.  This  is  the  proper  method  to  use  when  the  body  is  moving  through  a  flow.  Wave  motion 
causes  the  water  surrounding  the  vehicle  to  move  as  a  whole.  As  the  wave  moves  down  the  length  of 
the  vehicle  the  water  column  surrounding  the  vehicle  is  elevated  until  the  crest  passes  and  then  it  is 
lowered  through  the  trough.  The  movement  of  the  water  column  has  an  effect  on  the  position  and 
orientation  the  vehicle.  The  cross-body  drag  present  is  large  enough  not  to  be  ignored.  With  that  in 
mind  it  becomes  evident  that  the  most  accurate  way  to  simulate  wave  effects  is  by  evaluating  the 
movement  of  the  water  column  surrounding  the  vehicle  at  every  time  step,  and  treating  that 
movement  as  piecewise  forces,  derived  from  vertical  and  horizontal  velocities. 

Having  decided  on  the  proper  interaction  between  wave  and  vehicle,  one  must  now  evaluate 
the  interval  at  which  to  measure  the  water  column.  The  length  of  the  Phoenix  AUV  is  relatively  small, 
7.3  ft,  when  compared  to  the  average  wavelength  of  a  low  sea  state.  In  a  sea  state  of  1  the  average 
wavelength  is  20  ft.  From  the  buoyancy  model  already  in  place  calculations  are  performed  for  15 
segments  along  the  body.  Continuing  this  convention  for  the  surrounding  water  column  provides  a 
measurement  every  6  inches.  This  accuracy  is  more  than  sufficient  given  the  relative  size  of  the 
Phoenix  AUV  as  compared  to  the  wave.  This  methodology  allows  the  hydrodynamics  model  to 
calculate  a  force  vector  representing  the  water  column  surrounding  the  vehicle  at  the  center  of  each  of 
the  15  body  segments. 

The  final  issue  to  address  when  discussing  the  extension  of  the  buoyancy  model  to  include 
wave  effects  is  how  to  apply  these  new  force  vectors  to  the  vehicle.  Superposition  of  forces  is 
performed  in  a  way  which  is  physically  accurate  and  provides  a  realistic  animation  in  the  virtual 
environment. 

As  a  wave  moves  along  the  length  of  the  Phoenix  AUV's  body  force  vectors  are  created 
representing  the  direction  and  magnitude  with  which  the  water  column  is  moving  at  that  time  step. 
Using  these  vectors  it  is  now  possible  to  adjust  the  buoyancy  of  each  vehicle  segment  to  include  wave 
motion.  For  each  individual  segment  the  buoyancy  and  wave  force  vectors  are  calculated.  Then  the 
overall  effect  on  vehicle  position  and  orientation  is  arrived  at  by  adjusting  vehicle  buoyancy  and  the 
center  of  buoyancy.  Vehicle  buoyancy  and  vehicle  center  of  buoyance  are  determined  using  the 
(Bacon,  1996)  methods.  The  calculations  are  based  on  the  equation: 

Buoyancy  =  pgj  I  I dV 
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where  p  is  the  density  of  water, 
g  is  gravity,  and 

J  d  V   is  the  volumetric  displacement  of  a  submerged  (or  partially  submerged)  body  section 

at  any  given  time. 

This  provides  an  estimated  value  for  buoyancy  which  is  based  on  the  body  segments  which  are 
actually  displacing  water.  If  it  is  the  case  that  a  portion  of  the  vehicle  is  exposed  due  to  a  passing 
wave,  that  section  does  not  contribute  to  the  vehicle  overall  buoyancy  and  the  center  of  buoyancy  is 
adjusted. 

The  forces  created  by  the  flow  of  the  water  particles  moved  by  the  wave  are  applied  to  the 
vehicle  via  cross-body  drag  calculations.  The  wave  forces  are  originally  determined  in  world 
reference  frame  as  velocities.  Thus  these  values  must  be  translated  into  the  local  frame  and  applied 
along  the  length  of  the  vehicle.  The  translation  is  done  using  the  following  equation: 


u 

X  -dot 
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Y  -dot 

R 

w 

Z-dot 

where  u,  v,  and  w  are  body  reference  frame  velocities,  X-dot,  Y-dot,  and  Z-dot  represent  wave 
velocity  in  the  global  reference  frame,  and  [R]  is  the  rotation  matrix  (Healey,  1998). 

This  provides  a  approximation  which  is  both  visually  accurate  and  physically  correct.  The 
development  of  an  accurate  buoyancy  model  has  led  to  significant  advances  in  the  simulation  of 
underwater  vehicle  characteristics.  It  is  now  possible  to  simulate  proper  vehicle  behavior  when 
submerged,  surfaced,  or  operating  in  the  surf  zone.  Taking  into  account  simplifying  assumptions 
(such  as  how  wave  motion  affects  vehicle  position  and  orientation)  it  allows  for  real-time  modeling 
while  maintaining  a  physically  correct  basis.  Through  extending  this  model  to  include  the  effects  of 
wave  motion  on  vehicle  dynamics,  another  step  has  been  made  towards  accurately  simulating  all 
aspects  of  the  ocean  environment.  One  crucial  final  step  remains  which  is  deferred  as  future  work:  in- 
water  validation  of  predicted  model  results.  Nevertheless,  current  behavior  is  visually  and 
algorithmically  correct  enough  to  justify  development  of  more  robust  vehicle  control  laws. 
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D.       WAVE  MOTION  SIMULATION 

Underwater  vehicle  design  and  construction  is  almost  completely  preoccupied  with 
environmental  considerations.  The  ocean  completely  surrounds  the  vehicle,  affects  the 
slightest  nuance  of  vehicle  motion  and  poses  a  constant  hazard  to  vehicle  survivability.  Many 
of  the  effects  of  the  surrounding  environment  on  a  robot  vehicle  are  unique  to  the  underwater 
domain.  Vehicles  move  through  the  ocean  by  attempting  to  control  complex  forces  and 
reactions  in  a  predictable  and  reliable  manner.  Thus  understanding  these  forces  is  a  key 
requirement  in  the  development  and  control  of  both  simple  and  sophisticated  vehicle 
behaviors  (Brutzman,  1994). 

With  this  insight  one  realizes  that  in  order  to  provide  an  arena  for  the  proper  development  of 
such  a  complex  robot,  the  art  and  science  of  modeling  underwater  environmental  disturbances  must 
be  mastered.    These  effects  must  be  coupled  and  studied  with  underwater  vehicle  underwater  control 
and  dynamic  behavior  in  order  to  accurately  model  reality. 

Environmental  disturbances  play  a  significant  role  in  marine  control  applications.  Their  effects 
dictate  how  vehicles  are  designed,  constructed  and  eventually  driven.  For  these  reasons  the  physics  of 
the  sea  have  been  studied  for  many  years.  The  major  areas  of  interest  can  be  broken  down  into  three 
broad  categories:  wind,  ocean  currents,  and  wind-generated  waves. 

Each  one  of  these  forces  is  important,  having  a  significant  effect  on  both  the  novice  and 
expert  ocean  traveler.  The  wind  plays  a  major  role  in  the  design  of  ocean-going  vehicles,  but  in  the 
underwater  domain  its  direct  affects  are  minimal.  For  this  reason  the  introduction  of  wind  to  the 
underwater  virtual  environment  dynamics  model  is  not  required.  It  will  be  left  to  those  interested  in 
surface  modeling  and  simulation  to  implement  wind  in  their  appropriate  environments. 

Ocean  currents  are  another  environmental  disturbance  which  needs  to  be  evaluated.  Any  ocean 
navigator  recognizes  the  effects  of  set  and  drift.  Ignoring  their  influence  can  be  a  fatal  mistake.  These 
currents  are  also  applicable  when  discussing  submerged  vehicles.  They  exist  throughout  the  world 
and  have  a  large  effect  in  terms  of  vehicle  control.  In  fact  the  majority  of  areas  where  a  robot  of  this 
type  would  be  employed  have  significant  currents  (i.e.  harbors  or  river  outlets)  and  so  ocean  current 
must  be  dealt  with. 

This  work  uses  two  complementary  approaches  to  the  simulation  of  ocean  currents.  The  first 
addresses  the  local  frame  of  reference  and  the  second  the  global  frame  of  reference.  Locally,  the  AUV 
is  influenced  by  a  set  and  drift  which  are  present  in  the  area  of  operation.  The  direction  and  force 
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associated  with  the  current  is  calculated  and  factored  into  the  position  calculation  at  every  time  step. 
This  provides  a  very  simple  and  accurate  modeling  of  local  currents  and  their  affects  on  the  AUV. 

The  driving  force  behind  much  of  this  simulation  is  to  provide  an  ability  to  accurately  simulate 
the  forces  an  AUV  will  likely  encounter  while  trying  to  rendezvous  with  a  submarine  in  the  open 
ocean.  For  this  type  of  maneuver  both  vehicles  remain  in  a  relatively  small  area.  For  example,  if  the 
entire  evolution  was  to  take  1  hour  with  a  submarine  at  a  maximum  speed  of  3  kt  then  the  total  area 
traversed  is  only  6000  yds.  This  is  a  small  area  when  contrasted  with  the  vast  expanse  of  the  ocean. 
Thus,  while  in  the  global  frame  of  reference  there  may  be  many  different  currents  to  evaluate  and 
apply  to  vehicles  in  the  vicinity,  for  our  purposes  it  can  be  assumed  that  both  the  AUV  and 
submarine  are  subject  to  the  same  set  and  drift.  This  assumption  provides  a  useful  advantage.  Since 
both  vehicles  are  influenced  by  an  equivalent  set  and  drift  the  relative  motion  between  the  two 
vehicles  induced  by  these  currents  are  insignificant.  This  result  provides  additional  computational 
simplification:  relative  motion  between  the  AUV  and  submarine  due  to  steady-state  ocean  current  (set 
and  drift)  no  longer  needs  to  be  calculated. 

Ocean  currents  are  a  major  factor  in  both  ocean  navigation  and  ocean  simulation.  For  that 
reason  the  virtual  environment  developed  for  the  Phoenix  AUV  fully  accounts  for  the  effects  of  these 
environmental  forces. 

Wind-generated  waves  affect  both  surface  vessels  and  submersibles  which  operate  at  shallow 
depths.  The  process  of  wave  generation  due  to  wind  begins  with  small  wavelets  appearing  on  the 
water  surface.  This  increases  the  drag  force  which  in  turn  allows  short  waves  to  grow.  These  short 
waves  continue  to  grow  until  they  finally  break  and  their  energy  is  dissipated.  It  is  observed  that  a 
developing  sea  or  storm  starts  with  high  frequencies  creating  a  spectrum  with  peak  at  a  relative  high 
frequency.  A  storm  which  has  been  blowing  for  a  long  time  (and  has  reached  quasi-equilibrium)  is 
said  to  create  a  fully  developed  sea.  After  the  wind  has  stopped  blowing,  low  frequency  decaying  sea 
or  swell  is  formed.  These  long  waves  form  a  spectrum  with  a  low  peak  frequency.  Wind-generated 
waves  are  usually  represented  as  a  sum  of  a  large  number  of  wave  components  (Fossen,  1990). 

As  early  as  1952  researchers  were  developing  mathematical  representations  of  wind- 
generated  wave  phenomena  (Fossen,  1990).  Their  efforts  laid  the  groundwork  for  the  definition  of  a 
wave-field  spectral-density  function.  In  addition,  a  large  amount  of  data  has  been  collected  via 
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observations.  By  comparing  observed  data  with  the  mathematical  formulations  it  has  been  concluded 
that  the  spectral  density  of  the  energy  spectrum  as  a  function  of  wave  frequency  is  sufficient  to 
describe  a  wave  environment  of  fully  developed  long-crested  seas  (Reidel,  Healey,  1997).    This 
frequency  spectrum  can  be  represented  as 
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where  a  and  P  are  empirical  constants  defining  the  spectrum,  g  is  the  acceleration  of  gravity,  w  is  the 
frequency,  and  Vis  the  wind  velocity.  Equation  (4.1)  describes  a  general  frequency  spectrum  which 
can  be  used  to  fit  many  observations.  To  make  this  formulation  more  specific  there  are  several 
alternative  values  for  a  and  p.  One  can  use  the  Neumann  formula,  Pierson-Moskowitz  (P-M)  formula, 
the  Bretschneider  formula,  or  the  International  Ship  Structure  Formula  to  name  a  few  (Fossen,  1990). 
The  most  common  of  these  is  the  P-M  spectrum.  In  the  P-M  spectrum  typical  values  are  a  =  0.008 1 
and  p  =  0.74. 

Inserting  values  for  a,  P,  and  g  along  with  some  simplification  based  on  the  relationship 
between  significant  wave  height  (Hs)  and  wind  velocity  (V),  a  simplified  version  of  the  P-M  spectrum 
can  be  arrived  at  (Reidel,  Healey,  1997).  Formula  (4.2)  is  the  simplified  P-M  spectrum. 
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Using  the  P-M  spectrum  provides  the  spectral  density.  This  information  is  used  to  find  the 
wave  amplitude,  which  is  needed  in  order  to  apply  the  movement  of  the  water  column  to  the  AUV  as 
described  in  section  B  above.  The  wave  amplitude  can  easily  be  represented  in  terms  of  spectral 
density  as  follows: 

A2=2S(0))AC0  (4.3) 

Here  A  is  the  amplitude  and  Aa)  is  the  difference  in  successive  wave  frequencies  (Fossen,  1990). 
From  this  equation  the  amplitude  of  a  wave  of  interest  to  the  position  and  orientation  calculations  of 
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the  AUV  can  be  arrived  at.  From  here  it  is  necessary  to  compute  the  value  of  wave  amplitude  at  the 
prescribed  intervals  along  the  vehicle  body.  Calculating  and  combining  these  many  values  quickly 
becomes  computationally  expensive.  The  final  formulation  for  this  approach  to  wave  simulation  is 
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where  t  is  time  in  seconds,  freq  is  wave  frequency  in  radians  per  second,  X  is  wavelength  in  ft,  and  dx 
is  the  distance  along  the  vehicle  body. 

As  indicated  by  the  above  derivation,  wave  spectra  are  complicated  and  computationally 
expensive.  It  is  difficult  to  perform  this  type  of  analysis  as  part  of  a  real-time  simulation.  Luckily  the 
diligence  and  hard  work  of  researchers  over  the  past  45  years  alleviates  the  computational  burden 
through  published  data  tables  for  various  wave  spectra.  These  tables  are  the  result  of  countless  hours 
of  hard  work  and  provide  a  solid  basis  for  wave  simulation.  Table  4.2  is  an  excerpt  from  a  table  found 
in  (Bertaux  1976).  It  gives  all  the  pertinent  data  required  to  approximate  the  P-M  spectrum  in  any  sea 
state  ranging  from  0-9.  The  fields  of  interest  are  significant  wave  height,  frequency,  and  wavelength. 
With  this  information  the  state  of  a  wave  at  any  given  time  step  along  the  body  of  the  AUV  can  be 
calculated. 
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Sea  State 

Average 

Significant  Wave 

Height  (ft) 

Average  Period 
(seconds) 

Average  Wave 
Length  (ft) 

Minimum 
Duration  (hours) 

0 

0.05 

0.5 

1.0 

18  min. 

1 

0.18 

1.4 

6.7 

39  min. 

2 

0.6 

2.4 

20.0 

1.7 

3 

2.9 

4.6 

71.0 

6.6 

4 

4.3 

5.4 

99.0 

9.2 

5 

6.4 

6.3 

134.0 

12.0 

6 

11.0 

7.9 

212.0 

20.0 

7 

21.0 

10.3 

363.0 

34.0 

8 

36.0 

12.5 

534.0 

52.0 

9 

64.0 

16.3 

910.0 

88.0 

Table  4.2.  Characteristics  of  a  fully  arisen  sea.  Excerpts  taken  from  (Bertaux,  1976). 

Having  this  data  in  the  form  of  a  lookup  table  at  program  run  time  gives  the  ability  to 
dynamically  apply  the  affects  of  a  fully  developed  sea  state  to  the  vehicle.  The  computational 
advantage  gained  is  tremendous.  Equation  4. 1  shows  how  a  single  wave  can  be  applied  to  one  section 
of  the  vehicle  using  the  lookup  values. 
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where,  Hs  is  the  significant  wave  height,  t  is  time,  A  is  wave  length,  and  dx  is  the  distance  along  the 
AUV  body.  This  allows  the  instantaneous  height  of  a  wave  to  be  calculated  for  each  segment  of  the 
AUV  body.  This  height  is  then  transformed  into  a  buoyancy  force  as  previously  described  in  section  B 
above. 
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Lookup  tables  also  present  the  possibility  of  changing  sea  state  during  simulation.  Although 
this  functionality  is  currently  implemented  it  is  important  to  point  out  that  sea  state  cannot  change  in 
nature  instantaneously.  Nevertheless,  looking  ahead  to  long-term  scenarios  simulating  multiple  days 
at  sea,  it  is  a  worthy  feature  and  was  included  in  the  implementation. 

Wind-generated  waves  have  an  important  role  when  attempting  to  simulate  the  physical  nature 
of  the  ocean  environment.  They  are  the  most  complex  of  the  environmental  disturbances  adding 
significant  computational  complexity  to  ocean  simulation.  Despite  this  complexity  their  workings  are 
well  known.  Over  40  years  of  study  have  lead  to  the  ability  to  accurately  simulate  this  phenomenon  in 
a  real-time  virtual  environment. 

Environmental  disturbances  are  major  factors  to  consider  when  simulating  the  ocean 
environment.  They  are  an  ever-present  force  which  all  sea  going  vessels  must  deal  with,  whether 
surfaced  or  submerged.  Wind,  ocean  currents  and  wind-generated  waves  are  significant  factors  which 
must  be  accurately  simulated  to  guarantee  the  success  of  any  vehicle  developed  for  operation  at  sea. 

E.        COMPLEX  FLOW-FIELD  SIMULATION 

Another  field  which  must  be  addressed  in  terms  of  creating  a  physically  based  underwater 
simulation  environment  is  fluid  mechanics.  Fluid  mechanics  is  an  area  of  study  concerned  with 
observing  fluid  behaviors  in  order  to  utilize  and  control  the  effects  of  fluid  movement  for  the  benefit 
of  society  (James,  Haberman,  1988).  There  are  many  laws  describing  the  behavior  of  fluids  in  motion 
and  various  methods  of  applying  them.  These  laws  provide  the  insight  needed  to  successfully  model 
important  aspects  of  the  ocean  environment. 

The  forces  generated  by  fluid  movement  are  of  particular  concern  for  the  problem  at  hand: 
torpedo  tube  docking  of  an  AUV.  When  a  body  moves  through  a  liquid  it  displaces  an  amount  equal 
to  its  volume.  This  displaced  volume  of  fluid  generates  forces  as  it  moves  and  in  turn  can  apply 
substantial  force  to  other  bodies  in  the  area.  These  forces  become  significant  when  considering 
torpedo  tube  docking  for  several  reasons. 

Torpedo  tube  docking  is  a  high-risk  evolution.  There  are  many  things  which  must  be  evaluated 
before  this  type  of  exercise  can  be  conducted.  A  primary  area  of  concern  is  of  safety,  for  personnel 
and  for  both  vehicles.  A  mistake  or  accident  can  place  the  submarine  and  her  crew  in  great  danger. 
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Depending  on  the  nature  of  the  accident,  damage  can  range  from  compromising  the  submarines 
water-tight  integrity,  to  creating  a  noise  hazard  making  the  submarine  easily  detectable  by  adversaries, 
to  crippling  the  submarine  by  damaging  the  propeller  or  towed  sonar  array. 

In  order  to  avoid  the  above-mentioned  problems,  it  is  of  paramount  importance  that  the 
development  of  AUV  technology  be  thoroughly  tested.  To  that  end  it  is  necessary  to  ensure  that  this 
type  of  flow  simulation  can  be  done  in  real  time.  Real-time  feedback  provides  useful  insight  into 
vehicle  behavior  in  such  a  complex  environment.  It  gives  both  designers  and  users  a  chance  to  view 
vehicle  behavior  and  actively  discuss  improvements.  The  simulation-based  design  (SBD) 
methodology  is  a  major  factor  in  assuring  that  finished  products  meet  user  requirements.  For  that 
reason,  it  is  essential  for  robot  development. 

Another  aspect  to  the  importance  of  body-induced  flow  has  to  do  with  the  relative  size  of  the 
AUV  versus  that  of  a  submarine.  Figure  4.4  shows  the  difference  in  size  between  the  two  vehicles. 
The  overall  submerged  displacement  of  a  688-class  submarine  is  6900  tons,  with  a  length  of  360  ft 
and  a  30  ft  beam.  When  this  is  compared  to  the  AUV,  which  in  the  case  of  Phoenix  is  435  lbs 
displacement,  7  ft  length  and  1.5  ft  beam,  it  becomes  obvious  that  the  force  of  the  water  displaced  as  a 
submarine  moves  in  the  area  of  the  AUV  must  be  evaluated  and  accounted  for. 

Flow  instabilities  are  also  present  along  the  hull  of  the  submarine.  These  instabilities,  although 
small  when  compared  to  the  amount  of  flow  generated  by  the  moving  submarine,  can  be  enough  to 
cause  major  AUV  control  problems.  Large  variations  in  the  force  and  magnitude  of  movement 
surrounding  the  vehicle  must  be  planned  for  during  AUV  testing  and  development.  By  accurately 
simulating  these  variations  control  algorithms  can  be  tested  to  ensure  vehicle  stability  in  even  the 
worst-case  flow  situation. 

The  reasons  why  this  type  of  physically  based  simulation  is  needed  are  plentiful.  The 
questions  to  address  now  include  the  methodology  used  in  creating  such  a  simulation  and  any 
assumptions  made  to  ensure  real-time  performance. 

Intuition  tells  that  since  these  local  forces  exist,  they  must  be  applied  to  every  vehicle  they 
affect.  In  other  words,  the  submarine  creates  a  significant  field  which  must  be  felt  by  the  AUV  and 
any  other  vehicles  around,  while  the  AUV  simultaneously  generates  its  own  field  which  affects  the 
submarine.  Herein  lies  the  first  simplification.  Looking  again  at  the  size  difference  between  the 
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submarine  and  AUV  in  Figure  4.4  makes  it  obvious  that  the  displacement  force  created  by  the  AUV  is 
not  significant  from  the  submarines  perspective.  In  fact,  it  can  be  ignored  completely.  Since  water 
displacement  is  entirely  dependent  on  the  size  and  shape  of  the  vehicle  doing  the  displacement,  it  is 
necessary  to  determine  the  induced  flow  on  a  vehicle-by-vehicle  basis,  taking  into  account  all  the 
details  of  the  hull  in  question.  This  quickly  becomes  too  computationally  expensive  for  a  real-time 
simulation  system.  Nevertheless,  limiting  the  calculations  to  one  side  of  the  interaction  reduces  the 
problem  by  one  half,  a  significant  improvement. 


Figure  4.4.  Phoenix  AUV  size  (center  of  image)  versus  688  class  submarine. 


Inside  the  virtual  environment  an  area  of  influence  which  surrounds  the  submarine  was  created 
to  represent  the  flow  field.  This  volume  encapsulates  all  the  possible  positions  that  the  AUV  can  be  in 
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which  are  affected  by  the  presence  of  the  submarine.  Figures  4.5  and  4.6  give  a  visual  representation 
of  this  field,  with  Figure  4.5  showing  the  side  view.  It  demonstrates  that  the  field  exists  from  bow  to 
stern  of  the  submarine.  This  size  field  allows  modeling  the  approach  of  the  AUV  from  any  position 
along  the  hull  of  the  submarine. 


Figure  4.5.  Side  view  of  688  class  submarine  surrounded  by  its  field  of  influence. 

While  forces  do  exist  forward  and  aft  of  the  submarine,  they  are  not  of  concern  when 
considering  a  torpedo  tube  docking  solution,  since  it  is  assumed  that  for  the  docking  evolution  the 
AUV  will  always  approach  from  aft  of  the  torpedo  tube  door,  and  it  will  not  take  a  path  which  is 
crosses  any  of  the  turbulent  flow  created  behind  the  submarines  propeller.  These  are  reasonably  valid 
assumptions.  An  approach  from  aft  of  the  torpedo  tube  door  is  a  necessary  fact.  This  is  because  the 
submarine  must  always  maintain  forward  headway  to  ensure  adequate  depth  and  heading  control.  If 
the  AUV  were  to  make  an  attempt  at  docking  from  forward  of  the  submarine,  the  relative  speed 
would  be  too  large  to  ensure  safety  and  proper  control  for  the  evolution.  Therefore,  the  orientation  of 
the  torpedo  tube  door  must  allow  rear  entry.  Figure  4.7  shows  a  proposed  outer  door  configuration  for 
AUV  recovery.  This  provides  a  unique  advantage  when  conducting  the  recovery  evolution.  Adjusting 
the  door  to  move  outward  has  an  advantage  of  being  a  relatively  simple  modification  to  the  current 
outer  torpedo-tube  door  configuration,  and  also  provides  a  sheltered  lee  for  the  AUV  to  move  into. 
This  lee  creates  a  volume  of  water  for  the  AUV  to  perform  difficult  portions  of  the  docking  maneuver 
while  sheltered  from  most  open- water  flow. 
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Figure  4.6.  Front  view  of  688  class  submarine  surrounded  by  its  field  of  influence. 

An  approach  from  the  area  directly  astern  of  the  submarine  is  not  a  feasible  alternative.  The 
reason  behind  this  is  inherent  in  the  AUV  mission.  One  of  the  primary  missions  for  an  AUV  is  mine 
detection  and  avoidance.  The  circumstances  under  which  this  type  of  mission  is  conducted  are 
normally  those  associated  with  a  higher  degree  of  military  readiness  due  to  the  presence  of  a  possible 
threat.  Standard  operating  procedure  for  a  submarine  in  that  type  of  environment  requires  deployment 
of  a  towed  array  for  enhanced  enemy  detection  and  acoustical  monitoring.  With  such  a  tactically 
valuable  (and  expensive)  piece  of  equipment  trailing  from  the  stern  of  the  submarine,  this  path 
becomes  unavailable  for  AUV  recovery.  Thus  the  AUV  is  expected  to  choose  an  approach  from 
behind  that  is  along  one  side  of  the  submarine,  vice  fully  astern. 

With  that  in  mind,  Figure  4.6  gives  a  better  view  of  the  relative  area  enclosed  inside  this  flow 
field.  The  cylindrical  area  extends  a  distance  of  30  ft  from  the  side  of  the  hull  giving  the  area  a  total 
diameter  of  90  ft.  Outside  this  arbitrary  volume  submarine-induced  flow  forces  are  assumed  to  be 
negligible. 
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Figure  4.7.  AUV  docking  with  outward  opening  torpedo  tube  door. 

Having  examined  the  size  and  orientation  of  the  computational  model  for  the  flow  field,  it  is 
now  necessary  to  examine  what  makes  up  this  virtual  flow  field.  The  field  is  comprised  of  vectors  at 
Vz  ft  intervals.  Each  one  is  contains  a  flow  component  in  the  X,  Y,  and  Z  direction.  The  vector 
represents  the  total  amount  of  flow  force  (in  knots)  felt  by  the  vehicle  hull  at  that  location  relative  to 
the  submarine.  Graphically,  one  planar  slice  of  the  flow-field  velocity  looks  like  Figure  4.8. 

This  type  of  grid  extends  to  cover  the  entire  volume  within  the  cylindrical  area  of  influence 
surrounding  the  submarine.  The  orientation  is  such  that  the  innermost  row  of  flow  vectors  is  flush 
with  the  hull  and  the  outermost  follows  a  line  30  ft  out  from  the  hull.  An  exact  flow  vector  within  the 
grid  is  easily  found  through  position  comparison  between  the  AUV  and  submarine. 
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Figure  4.8.  Grid  Level  inside  submarine  flow  field. 

The  construction  of  the  flow  field  provides  some  distinct  advantages  in  terms  of 
hydrodynamic  modeling.  In  section  B  of  this  chapter  the  high-resolution  buoyancy  model  was 
presented  dividing  the  AUV  body  into  15  slices.  With  an  AUV  length  of  7.8  ft  this  breakdown 
corresponds  rather  nicely  to  Vi  ft  per  slice.  Thus  there  is  a  direct  correspondence  between  the  size  of 
the  grid  and  the  distance  between  the  center  of  each  section  along  the  AUV  body.  This  allows  for 
rapid  flow  vector  cross-referencing  and  application  during  the  cross-body  drag  calculations.  There  is 
no  need  to  interpolate  between  grid  positions  when  retrieving  flow  vectors  for  each  subsection  of  the 
vehicle.  In  fact,  the  vehicle  can  move  through  the  flow  field  at  any  random  orientation  and  an  exact 
position  is  rapidly  determined  for  the  flow  force  component  seen  by  each  section. 

The  flow  field  design  eases  computational  complexity  in  another  area  as  well.  After  the 
vehicle  position  is  determined  and  the  flow  force  vector  retrieved  it  must  be  applied  to  the  vehicle 
through  the  equations  of  motion  (EOM).  However,  by  tying  the  flow  field  vectors  to  the  submarine 
(global)  coordinate  system  these  forces  are  not  in  the  AUV  (local)  coordinate  system.  In  order  to  use 
them  in  the  EOM  we  must  translate  them  into  the  local  system.  Looking  at  the  flow  field  from  the 
AUV  point  of  view,  with  the  submarine  on  a  course  of  North,  it  can  be  said  that  no  matter  where  the 
vehicle  moves  in  the  world  coordinate  system  these  velocities  will  be  present.  Flow  field 
contributions  are  essentially  analogous  to  the  world  velocities  X-dot,  Y-dot,  Z-dot,  where  X-dot 
represents  the  linear  velocity  along  the  North-South  axis,  Y-dot  is  the  linear  velocity  along  the  East- 
West  axis,  and  Z-dot  is  the  linear  velocity  along  the  depth  axis.    This  gives  a  direct  relationship 
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between  the  flow  vector  velocities  and  those  which  can  be  used  in  the  vehicle's  hydrodynamic 
modeling.  The  velocities  can  be  rotated  from  the  world  coordinate  system  to  the  local  frame  of 
reference  as  follows: 


u 

X  -dot' 

V 

= 

Y-dot 

R 

w 

Z-dot 

(4.6) 


where  u  is  surge,  v  is  sway,  -w  is  heave,  and  R  is  the  (already  calculated)  rotation  matrix.  At  this 
point  we  finally  have  quantities  that  can  be  factored  into  the  calculation  of  the  vehicle's  cross-body 
drag  and  incorporated  into  the  EOM. 

Up  to  this  point,  a  distinct  methodology  has  been  presented  for  deriving  flow  forces  and 
applying  them  to  the  vehicle  being  affected.  The  next  step  is  to  elaborate  on  the  actual  data  that  is 
used  to  model  these  complex  flow  interactions.  While  looking  at  this  problem  several  objectives 
come  to  mind.  Typical  computational  fluid  dynamics  (CFD)  techniques  are  far  too  computationally 
complex  for  a  real-time  system,  so  flow  data  must  be  precalculated  whenever  possible  to  support  the 
simulation. 

Extensibility  is  at  the  core  of  this  approach  to  flow  modeling.  By  importing  flow  data  at  run- 
time, the  virtual  environment  can  be  used  as  a  test  bed  for  numerous  flow  regimes  and  control 
environments.  The  simulation  is  no  longer  bound  to  the  specific  case  for  which  it  was  developed  (i.e. 
tube  entry).  The  data  used  can  represent  any  type  of  flow  desired.  Additionally  as  advances  in  the  field 
are  made,  data  files  can  be  upgraded  to  provide  a  more  accurate  representation  of  the  fluid's  physical 
behavior.  The  only  requirement  is  that  the  data  files  maintain  a  readable  format,  and  that  requirement 
too  can  easily  be  manipulated. 

To  create  the  data  needed,  a  generation  program  was  developed  based  on  Fortran  source  code 
from  (Schetz,  1965).  The  original  program  generated  a  flow  profile  at  a  single  point  along  a  flat  plate 
using  a  two-dimensional  (2D)  approach  to  boundary  layer  incompressible  turbulent  flow.  In  order  to 
meet  the  needs  of  this  simulation  the  code  was  converted  to  C++  and  modified  to  include  the  flow 
models  required.  The  program  also  generates  output  data  files  which  are  imported  into  the  virtual 
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environment  when  a  docking  simulation  is  initiated.  The  code  for  this  program  is  included  in 
Appendix  D. 

There  are  two  models  which  are  used  to  create  the  flow  profile  down  the  length  of  the 
submarine:  one  for  areas  of  low  turbulence,  and  one  for  areas  of  high  turbulence.  The  majority  of  the 
submarine  hull  is  included  in  the  areas  of  low  turbulence;  for  these  sections  a  flat  plate  fluid  flow 
model  is  used.  The  turbulent  portions  use  a  tube-level  flow  model. 

1.  Flat-Plate  Fluid-Flow  Theory 

The  total  drag  on  a  body  is  due  to  the  sum  of  two  types  of  drag:  pressure  drag  and  skin  friction 
drag.  In  many  cases  one  of  the  two  types  of  drag  is  dominant  (John,  Haberman,  1988).  In  the  case  of  a 
submarine  moving  through  the  water,  pressure  drag  dominates. 

One  flow  model  which  has  many  similarities  to  the  application  in  which  this  data  is  going  to 
be  used  is  the  flat-plate  fluid-flow  model.  It  is  used  to  model  uniform  flow  over  a  flat  plate  aligned 
with  the  direction  of  the  flow.  Since  the  flow  in  question  is  created  by  the  submarine  moving  in  a 
specific  direction  through  the  water,  it  will  always  be  the  case  that  flow  is  aligned  with  the  flat  plate 
(i.e.  submarine  hull). 

Additionally  flat  plate  theory  assumes  that  over  90%  of  the  drag  caused  by  flow  is  pressure 
drag,  with  only  a  small  fraction  due  to  skin  friction.  Again  this  is  exactly  the  case  for  a  submarine 
moving  through  the  water.  The  shape  and  special  hull  treatment  of  a  submarine  are  designed 
specifically  to  reduce  skin  friction  and  reduce  undesirable  side  effects:  increased  noise  levels, 
reduced  propulsion  plant  efficiency,  etc.  It  can  intuitively  be  asserted  that  the  majority  of  drag  felt  by 
a  submarine  is  pressure  drag  due  to  the  amount  of  water  it  must  displace  to  move  through  the  water. 

One  remaining  question  regarding  model  suitability  is  whether  or  not  the  submarine  appears  to 
be  a  flat  plate  from  the  perspective  of  the  AUV.  Figure  4.9  shows  a  picture  of  the  AUV  next  to  the 
upper  1/3  of  a  688  class  submarine.  What  it  demonstrates  is  the  fact  that  the  side  of  the  submarine 
extends  10  ft  above  the  AUV  and  20  ft  below,  looking  very  much  like  the  AUV  against  a  wall  or  flat 
plate.  For  another  perspective,  one  can  look  at  Figure  4.4  to  get  a  wide  angle  view. 
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Figure  4.9.  Phoenix  AUV  seen  adjacent  and  parallel  to  the  upper  hull  of  a  688  class 
submarine. 


After  viewing  the  comparison  it  becomes  readily  obvious  that  using  flat  plate  fluid  flow 
model  to  simulate  the  flow  field  in  the  areas  of  low  turbulence  along  the  submarine  hull  is  a  good 
approximation. 

The  use  of  this  type  of  model  provides  excellent  simplification  of  the  run-time  flow 
calculations.  It  creates  simple  flow  vectors.  In  fact,  they  only  have  one  component  vice  three.  Due  to 
the  assumption  which  said  that  over  90%  of  the  drag  which  is  present  is  due  to  pressure  drag,  not 
friction  drag,  two  of  the  three  components  drop  out.  The  flow  force  is  only  present  along  the  axis  of 
the  plate.  This  means  that  of  the  three  flow  vector  components,  X-dot,  Y-dot,  and  Z-dot,  only  Y-dot  is 
a  nonzero  number.  The  overall  profile  extending  out  from  the  hull  is  shown  in  Figure  4.10. 
What  Figure  4.10  shows  is  how  flow  changes  as  one  moves  out  from  the  hull  of  the  submarine. 
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Initially  flow  is  at  0%  of  the  open  water  velocity  and  it  rapidly  increases  to  100%  as  the  distance  from 
the  hull  decreases.  This  demonstrates  that  the  effects  of  the  submarine's  presence  are  larger  as  the 
AUV  approaches  to  the  hull.  The  distance  at  which  flow  returns  to  the  open  water  value  is 
approximately  25-28  ft.  For  that  reason  the  flow  field  extends  30  ft  from  the  hull,  which  gives  a  small 
buffer  for  insertion  of  more  severe  flow  profiles.  It  is  also  interesting  to  note  that  as  the  distance  of  the 
vehicle  moves  from  the  bow  to  the  stern  the  percentage  of  open  water  flow  seen  by  the  vehicle  moves 
toward  100%  more  rapidly.  This  is  an  expected  phenomenon  when  using  a  flat-plate  approximation. 
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Figure  4.10.  Flat-plate  flow  profile  (generated  by  flow  generation  code)  versus  distance 
from  the  hull  of  a  688  submarine,  shown  at  5  locations  along  the  hull. 


The  flat-plate  fluid  flow  model  provides  an  excellent  match  for  areas  within  the  submarines 
field  of  influence  where  low  turbulence  is  expected.  The  assumptions  inherent  in  the  theory 
correspond  almost  directly  with  the  characteristics  of  the  problem  being  addressed.  This  approach 
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also  provides  a  nice  computational  advantage  since  this  profile  can  be  used  for  the  majority  of  the 
submarine. 

2.         Tube-Level  Fluid  Flow 

Some  areas  along  the  submarines  hull  cannot  be  approximated  by  the  flat  plate  model,  since 
they  are  subject  to  much  more  complex  flow  interactions.  For  the  submarine  docking  problem  at 
hand,  the  area  of  concern  surrounds  the  open  torpedo  tube  door,  beginning  slightly  ahead  of  the  door 
and  continuing  back  along  the  hull  until  flow  is  no  longer  disturbed  by  the  instabilities  caused  by  the 
open  door. 

This  type  of  flow  profile  is  similar  to  those  experienced  when  viewing  flow  over  a  cavity.  In 
this  case  the  torpedo  tube  outer  door  acts  as  a  shield  and  the  tube  area  is  the  cavity.  The  behavior  of 
flow  in  this  type  of  situation  is  very  complex  and  poorly  defined.  There  is  a  great  deal  of  active 
research  being  done  on  flow  fields  since  many  aspects  of  flow  behavior  are  poorly  understood.  What 
is  known  gives  enough  of  a  picture  of  the  flow  interaction  to  make  this  simulation  as  accurate  as 
possible. 

To  accurately  model  this  type  of  flow  there  are  three  portions  to  take  into  account:  the  flow 
approaching  the  tube,  the  flow  inside  the  cavity  (and  directly  aft  of  the  tube)  and  the  rest  of  the  flow 
path  from  aft  of  the  tube  to  the  stern. 

The  flow  area  forward  of  the  tube  is  easily  modeled.  As  flow  moves  along  the  hull  the 
protruding  torpedo  tube  door  forces  an  outward  movement  of  the  flow.  In  this  area  each  flow  vector 
now  has  a  magnitude  in  the  x  direction,  out  from  the  hull,  and  the  y  direction,  along  the  hull.  Figure 
4.11  portrays  the  overall  flow  picture  in  this  area. 


-50- 


Bow 


Stern 


Submarine  Hull 


^ 


-X 


Overall  Vector 


Figure  4.1 1.  Flow  interaction  as  it  approaches  an  open  torpedo  tube  door. 

Figure  4. 1 1  depicts  how  the  flow  moving  along  the  hull  is  forced  outwards  creating  a  flow 
force  vector  which  moves  away  from  the  hull  and  aft.  After  the  end  of  the  door  is  reached  the  flow 
interaction  becomes  very  complex.  In  this  area  a  dead  zone  is  created  inside  the  cavity.  In  the  cavity 
area  there  are  no  significant  flow  forces  at  all.  As  displaced  water  moves  back  into  the  area  behind  the 
torpedo  tube,  a  time-varying  flow-profile  is  created.  Vortices  are  created  at  varying  frequencies  along 
the  path  that  follows  the  door.  Figure  4. 12  gives  a  top-down  view  of  what  the  flow  profile  resembles 
at  a  given  moment.  The  dead  zone  represented  by  the  shaded  area  moves  along  with  the  submarine  as 
the  vortices  are  created  directly  aft  of  the  area.  Some  small  flow  aft  may  exist  in  this  dead  zone  if 
water  is  permitted  to  pass  through  openings  where  the  door  meets  the  hull.  Such  small  flow  may  also 
help  stabilize  turbulence. 
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Figure  4.12.  Flow  movement  aft  of  the  torpedo  tube  door. 

The  final  area  to  examine  is  aft  of  the  tube  disturbances.  In  this  area  flow  has  stabilized.  All 
the  complex  interactions  caused  previously  have  subsided.  Here  it  is  again  possible  to  model  the  flow 
field  as  a  flat  plate.  The  only  additional  disturbances  present  in  this  area  are  those  created  by  pump 
suctions  and  discharges. 

The  flow  interactions  present  on  the  tube  level  of  the  submarine  are  quite  complex.  This 
influence  is  time  varying  and  not  yet  fully  understood.  The  majority  of  the  interactions  take  place  on  a 
small  scale  (less  than  inches)  that  a  scale  of  Vi  foot  intervals  between  flow  measurements  can  only 
approximate.  In  this  simulation  the  variance  of  flow  in  this  situation  has  been  captured  at  a  low  level 
of  detail.  As  advances  are  made  in  the  understanding  of  fluid  flow  over  cavities  it  will  be  possible  to 
upgrade  the  resolution  of  flow  vector  data  used.  For  the  time  being  this  model  provides  a  plausibly 
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accurate  testing  environment  for  AUV  interaction  within  complex  flow  situations.  By  examining 
approximate  but  worst-case  conditions,  an  estimate  of  the  magnitude  of  flow  effects  can  be  simulated. 


F.        EQUATIONS  OF  MOTION  (EOM) 

The  Phoenix  AUV  virtual  environment  uses  a  Newton-Euler  approach  to  the  six  degree  of 
freedom  (DOF)  EOM.  This  accurately  models  the  kinematics  and  dynamics  of  a  rigid  body  vehicle 
moving  without  constraint  (Brutzman,  1994)(Healey,  1998).  These  equations  have  been  partially 
verified  through  extensive  testing  in  the  virtual  environment  coupled  with  in-water  mission  analysis. 
In  all  cases  the  results  experienced  in  the  virtual  environment  demonstrated  proper  behavior,  as 
evidenced  by  similar  results  during  in-water  runs  of  identical  missions.  Additional  testing  is  needed  to 
quantify  the  effects  of  recent  hardware  improvements  (such  as  larger  shrouded  propellers). 

In  order  to  properly  integrate  the  flow  forces  previously  discussed  into  the  virtual 
environment,  we  examine  the  EOM  looking  for  the  proper  terms  to  modify.  Equation  4.7  is  the  sway 
equation  of  motion  from  (Brutzman,  1994)  which  is  implemented  in  the  Phoenix  AUV  virtual 
environment. 

Sway  Equation  of  Motion  (4.7) 
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The  variables  and  coefficients  in  the  sway  equation  of  motion  are  defined  in  (Brutzman,  1994). 

The  terms  of  the  EOM  define  all  the  major  force  contributors  to  vehicle  motion.  Similar 
equations  exist  which  define  surge,  heave,  roll,  pitch,  and  yaw.  These  can  be  found  in  (Brutzman, 
1994).  For  this  discussion,  the  sway  equation  of  motion  is  used  as  an  example. 

For  the  problem  at  hand  it  is  necessary  to  integrate  the  additional  flow  force  contributions  into 
the  EOM.  Since  the  body-induced  flow  forces  are  primarily  due  to  the  cross-body  drag  of  the  water  as 
it  passes  over  the  vehicle,  the  logical  place  to  insert  these  factors  is  the  term  dealing  with  cross-body 
drag.  To  do  so  we  must  first  examine  precisely  how  these  velocities  induce  drag. 

1.  Round  Hull  Derivation 

Cross-body  drag  is  calculated  to  incorporate  the  force  generated  by  the  motion  of  water  over  a 
rigid  body.  When  determining  the  magnitude  and  direction  of  this  force  one  must  know  the  shape  and 
size  of  the  body  being  effected.  In  past  versions  of  the  EOM  it  has  been  assumed  that  the  shape  of  the 
body  was  always  cylindrical.  This  provides  a  solution  to  the  six  degree  of  freedom  model  that  is 
general  enough  to  accurately  depict  the  cross-body  drag  for  the  majority  of  submerged  vehicles. 


Incident  Force 


Resultant  Force 
Resultant  Force  =  Incident  Force 


Figure  4.13.  Flow  force  incident  upon  a  round  body. 


For  a  round  body  the  force  applied  by  the  water  is  always  in  the  same  direction  as  the  original 
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force.  When  calculating  the  cross-body  drag  the  v  and  w  components  can  be  found  by  the  breaking  the 
force  up  into  the  respective  components,  Fy  and  Fw,  then  normalizing.  Figure  4. 13  gives  a  visual 
representation  of  these  forces  and  their  components. 

The  terms  can  be  defined  mathematically  as  follows  (Healey,  1998): 

Fy  =  ^CDpv2dx  Fw  =  X-CDpw2dx  (4.8)  and  (4.9) 

Going  one  step  further  it  can  be  said  that 

v  =  v0  +  xr  (4-10> 

and 

w  =  w0  +  xq  (4.11) 

Taking  these  facts  and  adding  a  term  for  normalization  gives  the  final  version  of  the  cross-body  drag 
formulation. 

1           .           x2  (v  +  xr) 
Fy  =  TCDp(v  +  xr)  — dx  (4.12) 

^  U  cf 
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These  forces  are  incorporated  into  the  EOM  as  one  of  the  multiple  terms  present.  Translating 
the  forces  into  the  rigid  body's  reference  frame  and  integrating  their  effect  along  the  horizontal  axis  of 
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the  body  results  in  the  fifth  term  on  the  right  hand  side  in  the  sway  equation  of  motion. 

This  term  represents  the  effects  of  flow  forces  across  the  spherical  rigid  body.  As  is  evidenced 
by  the  derivation  of  the  forces,  shape  of  the  rigid  body  does  make  a  difference.  In  the  case  of  the 
Phoenix  AUV,  which  has  a  rectangular  shape,  this  generic  model  is  inaccurate. 

2.  Square  Hull  Derivation 

When  a  flow  force  is  incident  upon  a  rigid  body  that  does  not  have  a  spherical  shape  the 
direction  of  the  resultant  force  is  not  necessarily  the  same  direction  the  force  came  from.  Figure  4.14 
demonstrates  this  fact.  Given  a  force  incident  upon  a  rigid  body  with  a  shape  that  is  rectangular,  the 
resultant  force  is  not  equal  in  magnitude  or  direction  to  the  resultant  force. 

The  initial  formulation  from  the  round  hull  derivation  of  cross-body  drag  is  similar,  but  the 
terms  cannot  be  normalized  using  Ucf-  The  reason  for  this  is  that  Ucfis  radialized  and  it  is  no  longer 
the  case  that  the  forces  are  radially  symmetric.  This  causes  some  differences  to  exist  between  the 
cross-body  drag  term  in  the  EOM  for  a  spherically  shaped  body  versus  the  same  term  in  the  EOM  for 
a  non  spherical  body.  The  formulation  for  Fy  and  Fw  in  this  case  are  given  in  (4.14)  and  (4.15) 
(Healey,  1998). 
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Figure  4.14.  Flow  force  incident  upon  a  non-spherical 
rigid  body. 
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1  ,  ,2 

Fy  =-CDp(v  +  xr)  dx 


(4.14) 


(4.15) 


Taking  these  revised  force  formulations  and  incorporating  them  into  the  EOM  to  make  a  more 
specific  set  of  equations  yields  the  sway  equation  of  motion  given  in  (4.16).  This  equation  provides  an 
accurate  evaluation  of  cross-body  drag  and  is  computationally  less  complex  than  the  spherical  hull 
case.  Thus  it  provides  two  advantages.  Similar  specializations  are  performed  for  the  equations  of 
motion  for  heave,  pitch,  and  yaw. 


Square  Hull  Sway  Equation  of  Motion 
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In  order  to  improve  the  accuracy  of  the  Phoenix  AUV  virtual  environment  without  limiting  its 
extensibility,  both  models  are  incorporated  in  the  implementation.  The  user  can  select  the  shape  of  the 
hull  being  tested  in  the  virtual  environment,  and  based  on  that  selection  the  appropriate  version  of  the 
EOM  will  be  used. 

G.       SUMMARY 

The  environment  plays  a  major  role  in  all  aspects  of  AUV  research  and  design.  If  a  virtual 
environment  is  to  act  as  a  true  test  bed  for  newly  engineered,  devices  it  must  take  into  account  the 
forces  of  nature.  The  virtual  environment  used  for  testing  and  development  of  the  Phoenix  AUV 
incorporates  many  environmental  factors  into  its  simulation.  The  virtual  environment  is  truly 
physically  based.  The  enhancements  added  throughout  this  work  incorporate  a  highly  detailed 
buoyancy  model,  wave  motion  simulation  based  on  the  Pierson-Moskowitz  wave  spectrum,  a  detailed 
methodology  for  simulating  body  induced  flow  forces,  and  a  specialization  of  the  equations  of  motion 
to  offer  a  higher  resolution  method  for  modeling  cross-body  drag  on  non  spherical  rigid  bodies. 

All  of  these  factors  serve  to  enhance  the  realistic  behaviors  which  are  present  inside  the 
Phoenix  AUV's  virtual  environment.  Improvements  of  this  type  can  only  better  performance  leading 
to  improved  design,  testing,  and  final  product. 
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V.  IMPLEMENTATION 

A.  INTRODUCTION 

As  with  any  technically  based  research,  there  needs  to  be  some  proof  of  correctness  for  the 
various  theories  presented.  This  chapter  examines  two  separate  implementations  of  the  Phoenix 
AUVs  virtual  environment.  The  initial  implementation  was  done  using  C++  and  Silicon  Graphics 
Openlnventor  Application  Programmers  Interface  (API).  This  version  runs  solely  on  Silicon  Graphics 
workstations.  A  second  platform-independent,  implementation  was  created  to  run  on  any  machine 
upon  which  the  Java  runtime  environment  is  present.  Each  version  uses  the  DIS  protocol  for 
networking  enabling  the  user  to  run  a  mix  of  viewer  and  dynamics  versions  if  desired. 

B.  C++  AND  OPEN  INVENTOR 

The  virtual  environment  is  primarily  comprised  of  three  components.  In  their  original 
implementation  the  dynamics  program  was  written  in  C++,  robot  execution  level  in  C,  and  the  viewer 
in  C++  using  the  Openlnventor  API  (Brutzman,  1993).  Each  component  was  thoroughly  tested  and 
the  performance  was  validated  by  real-world  experiments.  With  this  history  in  mind,  the  logical 
choice  is  to  first  implement  the  flow  and  buoyancy  models  in  C++  before  the  transition  to  Java. 

The  wave  model  and  the  submarine-induced  flow  forces  both  relate  to  the  environments 
effect  on  the  AUV,  thus  both  are  implemented  in  the  dynamics  code.  The  code  itself  is  located  in  a 
function  called  calculate_equations_of_motion()  which  is  included  in  Appendix  A. 

The  algorithm  for  the  wave  model  uses  the  P-M  spectrum  as  discussed  in  Chapter  IV.  For  each 
time  step,  the  height  of  the  wave  is  calculated  for  the  fifteen  sections  down  the  AUV  body  length.  At 
each  block,  a  force  vector  proportional  to  the  wave  height  is  assigned.  After  stepping  down  the  length 
of  the  body  the  vectors  are  added  and  averaged  to  get  an  overall  force  that  acts  upon  the  entire  AUV. 
This  superposition  vector  is  used  to  adjust  the  center  of  buoyancy  of  the  vehicle  prior  to  completing 
the  integration  of  the  equations  of  motion.  The  overall  effect  is  a  pitching  moment  that  is  proportional 
to  the  wave  position  over  the  body  of  the  vehicle.  Figure  5. 1  presents  the  pseudocode  for  the  wave 
algorithm. 
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for  (  1  to  number  of  sections)      { 

Calculate  wave  motion  buoyancy  for  this  block 
if  (depth  >  20  ft)  { 

Reduce  wave  buoyancy  effect  due  to  depth 

} 

Determine  overall  direction  of  wave  motion 
}    //end  of  for  loop 

for  (  1  to  number  of  sections)  { 
Adjust  vehicle  buoyancy  based  on  wave  motion 
Adjust  center  of  buoyancy  based  on  direction  of  wave  motion  and  pitch  angle 

} 

high-resolution  buoyancy  force  calculation  complete 


Figure  5.1.  Pseudocode  for  wave  motion  effect  algorithm. 

The  next  algorithm  incorporated  into  the  equations  of  motion  provides  the  forces  created  by 
the  submarine's  flow  field.  As  described  in  Chapter  IV  the  flow  field  exists  in  the  area  of  water 
surrounding  the  submarine.  The  implementation  of  this  algorithm  is  more  complex  than  that  of  the 
wave  model.  It  requires  several  calculations  for  each  section  of  the  AUV  body.  Each  one  providing 
information  for  the  next  iteration  down  the  body.  Figure  5.2  contains  pseudocode  of  the  general 
algorithm. 

The  first  step  is  to  determine  whether  or  not  the  AUV  is  inside  the  influence  field  of  the 
submarine.  This  is  done  by  comparing  the  position  of  the  AUV  to  the  position  of  center  of  the 
submarine.  Having  knowledge  of  the  volume  of  water  which  falls  into  the  flow  field  allows  for  quick 
determination  of  whether  or  not  submarine  flow  interactions  must  be  calculated. 
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Compare  the  position  of  the  AUV  to  that  of  the  submarine 
if  (inside  flowfield)  { 
Set  flowfield  flag  to  TRUE; 

} 

for  (  1  to  number  of  sections  )  { 
Calculate  the  x-position  of  the  current  section 
Calculate  the  y-position  of  the  current  section 
Calculate  the  z-position  of  the  current  section 
Determine  the  position  of  the  AUV  relative  to  the  submarine  center 
Index  into  flow  field  matrix  and  retrieve  the  flow  force  at  that  point,  without  interpolation 


Calculate  a  rotation  matrix  to  translate  x,y,z  force  components  into  body  coordinates 

for  ( 1  to  number  of  sections)  { 

Translate  current  section  forces  into  body  coordinates 

//Cross  Body  Drag  Contribution 
Calculate  flow_field_sway_integral 
Calculate  flow_field_surge_integral 
Calculate  flow_field_heave_integral 
Calculate  flow_field_roll_integral 
Calculate  flow_field_pitch_integral 
Calculate  flow_field_yaw_integral 

} 

Add  flow  field  integrals  to  cross-body  drag  integrals 


Figure  5.2.  Pseudocode  for  flow  field  algorithm. 
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Once  it  is  determined  that  the  AUV  is  inside  the  flow  field,  more  detailed  calculations  are 
performed.  These  include  finding  the  position  of  each  section's  center  and  the  position  of  that  section 
inside  the  flow  field.  Figure  5.3  demonstrates  the  geometry  of  calculating  the  x  position  of  a  section. 
Knowing  the  heading  of  the  AUV  and  the  orientation  of  the  world  axis,  each  coordinate  position  can 
be  determined  using  simple  geometry.  A  similar  method  is  used  for  determining  the  y  and  z  values 
for  a  section  of  the  hull. 


AUV  Heading 


Distance 
from  AUV 
Center 


Heading 
Difference 


AUV_x 

Position 


Section  X       X-Axis 


X  =  AUV_x  +  sin  (90-Heading  Difference) 
*  distance  from  AUV  Center 


Figure  5.3.  Geometry  of  calculating  an  AUV  sections  X  position 
relative  to  the  center  of  the  AUV. 


Once  the  x,  y,  and  z  coordinates  of  a  body  section  have  been  determined,  they  are  used  to 
calculate  the  position  inside  the  flow  field.  This  process  takes  two  steps.  First,  the  relative  position  of 
the  AUV  to  the  submarine  is  determined,  then  the  relative  coordinates  are  converted  into  flow-field 
indices. 

The  X  component  represents  the  AUV  position  along  the  hull  of  the  submarine  with  a  value  of 
zero  ft  meaning  at  the  bow  and  360  ft  at  the  stern.  The  X  value  corresponds  to  the  distance  from  the 
bow  of  the  submarine  in  feet.  This  is  determined  by  simply  taking  the  difference  between  the  X 
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position  of  the  submarine  and  the  X  position  of  the  AUV. 

The  next  relative  position  component  is  the  radial  distance  of  the  AUV  from  the  centerline  of 
the  submarine.  It  combines  both  the  y  and  z  positional  components  into  a  single  number  (Equation 
5.1).  This  is  used  because  the  construction  of  the  flow  field  is  such  that  the  grid  is  anchored  at  the 
center  of  the  submarine.  To  get  at  any  particular  position  out  from  the  hull  the  overall  radial  distance 
is  needed  as  an  index. 


RadialDist  =  J\Y difference)   +  (Z difference)  (5.1) 


The  conversion  step  takes  the  X-position  with  the  radial  distance  and  then  converts  the  pair  to 
flow  field  indices.  The  numbers  cannot  be  taken  directly  because  the  grid  has  a  resolution  of  Yi  ft 
increments.  This  causes  the  grid  positions  to  range  from  zero  to  720  along  the  hull  and  zero  to  sixty 
out  from  the  hull.  The  conversion  simply  takes  the  calculated  coordinate  and  makes  it  into  an  integer 
position  which  can  be  used  in  the  flow  field  system. 

Having  the  proper  indices  available  it  is  now  possible  to  retrieve  the  values  of  flow  forces  seen 
by  the  section  of  the  AUV  being  considered.  The  flow  induced  forces  are  stored  velocities  in  the 
world  coordinate  system.  To  apply  them  to  the  equations  of  motion  in  the  local  coordinate  frame  they 
are  translated  into  body  coordinates  using  equation  (4.6).  No  interpolation  is  performed  due  to  already 
high  resolution,  reducing  computational  complexity.  The  forces  are  then  applied  to  the  EOM  by 
adding  their  effects  into  the  calculation  of  cross-body  drag. 

The  algorithms  for  wave  motion  and  body-induced  flow  forces  are  tightly  interlaced  in  the 
dynamics  code.  Many  of  the  calculations  required  for  the  wave  model  are  also  needed  for  the  flow 
field  and  vice  versa.  By  conducting  the  computations  in  tandem  the  added  execution  time  is  kept  to  a 
minimum.  It  enables  an  already  computationally  complex  virtual  environment  the  ability  to  become 
more  accurate,  yet  still  run  in  real-time. 

Other  changes  to  the  virtual  environment  involved  additions  to  the  viewer  program.  The 
viewer  provides  a  window  into  the  virtual  environment.  For  the  experiments  conducted  in  this  thesis 
it  is  necessary  to  visualize  the  AUVs  approach  and  rendezvous  with  a  submarine.  In  its  initial 
incarnation  the  virtual  environment  did  not  contain  a  submarine.  It  was  primarily  used  to  develop 
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robot  control  algorithms  for  open  water  situations.  It  also  provided  a  replica  of  the  NPS  test  tank  for 
small-area  testing  which  might  later  be  conducted  in  the  actual  tank.  As  the  focus  was  moved  away 
from  small-area  operations  to  open-water  docking,  a  688  class  submarine  model  was  added  to  the 
environment.  The  addition  turned  out  to  be  an  invaluable  visualization  tool  and  presented  an  added 
feeling  of  AUV  scale  in  the  open  ocean. 

Implementing  the  wave  buoyancy  model  and  the  body-induced  flow  algorithm  in  C++ 
provided  an  excellent  stepping  stone  in  the  development  process.  Knowing  the  original  version  of  the 
virtual  environment  was  validated  and  sound  allowed  for  quick  isolation  of  possible  modeling  errors. 
Any  instabilities  encountered  were  localized  to  either  of  the  new  algorithms.  It  also  provided  the 
groundwork  for  the  later  implementation  of  dynamics  in  Java.  In  summary:  development  and 
implementation  of  the  high-resolution  models  was  successful. 

C.       JAVA  AND  VIRTUAL  REALITY  MODELING  LANGUAGE  (VRML) 

After  proving  the  validity  of  the  models  proposed  by  this  thesis,  the  next  step  was  to  provide  a 
platform-independent  version  of  the  code.  This  was  not  possible  using  C++  and  the  Openlnventor 
API.  C++  is  plagued  by  compiler  differences  from  one  platform  to  another,  and  the  Openlnventor  API 
is  primarily  for  Silicon  Graphics  workstations,  although  a  port  of  the  library  to  Windows95  has 
recently  been  completed.  In  any  case  the  only  way  to  provide  true  platform  independence  was  to  use 
languages  which  were  not  platform  specific.  For  that  reason  Java  in  combination  with  VRML  are  the 
language  of  choice. 

The  first  portion  of  the  virtual  environment  converted  was  the  dynamics  program  and 
associated  functions.  This  was  a  relatively  straightforward  port  of  C++  to  Java.  While  some  problems 
were  encountered  due  to  differences  in  language  functionality  (i.e.  object  handling,  operator 
overloading,  pointers,  etc.)  it  was  more  time  consuming  than  complex.  Appendix  B  contains  a  list 
description  of  the  code  for  the  virtual  environment  dynamics  in  Java.  The  functionality  and  object 
hierarchy  of  the  dynamics  program  is  the  same  in  the  Java  and  C++  version,  as  is  most  program 
syntax.  Flow  field  matrices  proved  too  large  for  current  PC  Java  implementation,  so  this  section  of 
code  is  commented  out. 

The  second  step  in  the  move  towards  platform  independence  was  to  re-implement  a  viewer 


-64- 


program  in  a  platform-neutral  way.  VRML  was  used  to  describe  the  virtual  environment  scene  graph 
with  Java  as  the  language  to  animate  the  objects  in  the  environment.  This  gives  anyone  with  an 
Internet  browser  (and  appropriate  VRML  plug-in)  the  ability  to  view  the  virtual  environment. 

The  difficulties  in  porting  the  viewer  to  a  platform  independent  scheme  were  primarily  due  to 
problems  with  Internet  browsers  and  VRML  plugins.  Due  to  the  early  development  stage  of  both  of 
these  technologies,  many  inconsistencies  were  encountered.  These  implementation  problems  were 
handled  by  the  DIS-Java-VRML  working  group.  Numerous  work-arounds  and  problem  solutions 
were  developed  in  the  working  group  forum.  They  provided  the  Java  implementation  of  the  DIS 
protocol  and  the  bridge  from  multicast  broadcast  to  unicast  so  the  VRML  scene  can  be  animated  via 
the  script  node.  Figure  5.4  shows  the  underlying  architecture  of  the  Java- VRML  version  of  the 
Phoenix  AUV  virtual  environment.  The  source  code  for  the  VRML  scene  is  available  via  references 
in  Appendix  B.  The  source  for  the  DIS-Java-VRML  library  is  available  at 
[http:www.  stl.  nps.  navy,  mil/dis-java-vrml] . 


Execution 
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<^> 
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Figure  5.4.  Platform-independent  architecture  for  Phoenix  AUV  virtual  environment. 

The  transition  from  a  platform  specific  virtual  environment  to  a  platform-independent  one  is  a 
large  step  forward  in  simulation  technology.  As  personal  computers  become  better  and  platform- 
independent  languages  more  robust,  this  transition  can  only  get  easier. 
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D.       SUMMARY 

This  chapter  describes  two  separate  implementations  of  the  Phoenix  AUV  virtual 
environment.    The  C++/OpenInventor  version  is  an  extension  of  the  original  virtual  environment, 
providing  the  speed  and  additional  functionality  needed  to  perform  the  SBD  of  torpedo  tube  recovery, 
while  still  using  a  validated  base  environment  for  quick  isolation  of  problems.  The  DIS-Java-VRML 
implementation  gives  the  virtual  environment  portability.  It  is  now  possible  to  view  simulations  from 
any  machine  having  Internet  connectivity. 
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VI.     EXECUTION  LEVEL  AND  VIRTUAL  DOPPLER  SONAR 

A.  INTRODUCTION 

The  Phoenix  AUV  execution  level  software  controls  all  the  hardware  onboard  the  vehicle, 
ensuring  all  hard  real-time  deadlines  are  met.  It  uses  a  sense-decide-act  loop  to  iterate  through  the 
process  of  polling  sensor  and  effector  state,  deciding  what  actions  are  required  and  then  commanding 
devices  to  the  proper  state.  The  devices  that  are  controlled  range  from  motors  and  servos  to  gyros  and 
sonars.  This  chapter  discusses  a  new  sensor,  a  doppler  sonar  unit,  which  is  simulated  in  the  virtual 
environment  and  used  for  advanced  control  law  testing. 

B.  TRITECH  DS30  PRECISION  DOPPLER  SONAR 

Doppler  sonar  works  on  the  basic  theory  of  measuring  the  frequency  shift  in  a  transmitted 
signal.  The  TRITECH  DS30  precision  doppler  sonar  is  a  highly  accurate,  reliable,  compact  unit 
designed  for  underwater  vehicle  use.  It  provides  measurements  of  vehicle  speed  by  analyzing  the 
frequency  shift  in  the  back-scattered  signal  (MECCO,  1997).  The  DS30  is  comprised  of  three  major 
components:  a  digital  micro  controller,  an  analog  control  circuit,  and  a  transducer. 

The  digital  micro  controller  controls  the  transmitter,  the  receiver,  a  Programmable  Logic 
Device  (PLD),  and  manages  data  communications  to  an  external  control  device.  Data  output  provides 
a  bottom  speed  vector,  water  mass  speed  vector,  and  the  current  depth.  Both  vectors  can  be  presented 
in  either  polar  or  rectangular  format.  The  speed  vectors  are  given  in  meters  per  second,  with  an 
accuracy  of  one  centimeter  per  second  and  depth  indication  is  accurate  to  one  centimeter. 
Communication  with  the  sonar  is  conducted  through  a  9600  baud  serial  line.  This  line  handles  both 
data  output  and  command  input.  Figure  6. 1  gives  the  specification  data  for  the  DS30. 
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Power 24VDC 

Power  consumption 200  mA  average,  1  A  peak 

Operating  frequency 1  MHz 

Operating  range  for  seabed  tracking 2-30  meters 

Tracking  modes Velocity  relative  to  seabed  &  velocity  relative  to  seawater 

Data  rate Up  to  5  updates  per  second 

Communication RS232  as  standard,  RS485  as  option 

Operating  velocity 0-3.75  meters/second 

Velocity  accuracy 2.5  centimeters/second 

Velocity  resolution 0.5  centimeters/second 

Transducer 4  beam  Janus  array 

Configuration Convex,  beams  @  45°  to  vertical 

Source  level 217  dB  re.  1  uPa  @  1  meter 

Depth  rating 1000  meters 

Length 360  millimeters  including  connector 

Body  tube  diameter 120  millimeters 

Maximum  diameter 130  millimeters 

Weight  in  air 5.5  kilograms 

Weight  in  water 2  kilograms 


Figure  6.1.  Tritech  DS30  precision  doppler  sonar  specification  from  (MECCO,  1997). 

The  DS30  analog  control  circuit  is  comprised  of  one  receiving  channel  and  one  transmitting 
channel.  It  achieves  a  four-channel  system  by  multiplexing  the  receiver/transmitter  circuits  to  each 
transducer  element.  The  transducer  is  constructed  with  four  elements,  each  at  45  °  offset  from  the 
normal  axis  (MECCO,  1997).  Figure  6.2  is  a  picture  of  the  DS30  mounted  on  the  front  of  the  Phoenix 
AUV. 
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Figure  6.2.  Tritech  DS30  precision  doppler  sonar  mounted  on  the 
nose  of  the  Phoenix  AUV. 


The  Tritech  DS30  precision  doppler  sonar  is  a  unit  which  is  well  suited  to  the  Phoenix  AUVs 
needs.  It  is  an  accurate  sensor  which  can  be  easily  integrated  into  the  vehicle  due  to  its  low  cost,  low 
power  requirements,  and  standard  communication  setup.  The  DS30  provides  all  the  needed 
components  to  accurately  measure  cross-body  flow  and  use  that  information  for  enhanced  modes  of 
AUV  control. 
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C.   SONTEK  ACOUSTIC  DOPPLER  VELOCIMETER  (ADV) 

The  Sontek  acoustic  doppler  velocimeter  (ADV)  is  another  device  which  can  be  used  to 
determine  cross-body  flow  for  the  Phoenix  AUV.  It  is  an  acoustic  doppler  current  profiler  and  has  the 
ability  to  determine  water  velocity  in  three  component  axis.  The  Sontek  ADV  works  by  measuring  the 
velocity  of  a  volume  of  fluid  that  is  directly  above  its  probe  and  has  an  accuracy  of  0. 1 
millimeters/second.  This  type  of  technology  is  designed  to  accurately  measure  ocean  current,  and  it  is 
well  suited  to  be  used  as  a  cross-body  flow  sensor  on  the  Phoenix  AUV.  The  specifications  for  this 
device  are  given  in  Figure  6.3.  Eventually  in- water  testing  will  also  examine  whether  the  velocity 
update  rate  is  sufficient  fast  for  real-time  maneuvering  control. 


Power 24  VDC 

Power  consumption 3  Watts  average 

Operating  frequency 10  MHz 

Data  rate 0.1  to  25  Hz 

Communication RS232 

Operating  velocity 2.5  meters/second 

Velocity  resolution 0.1  millimeters/second 

Depth  rating 30  meters 

Length , 407.9  millimeters  including  connector 

Body  tube  diameter 76.2  millimeters 

Maximum  diameter 133.4  millimeters 


Figure  6.3.  SonTek  acoustic  doppler  velocimeter  (ADV)  specification  from  (SonTek,  1997). 

The  Sontek  ADV  is  a  new  device  which  is  specifically  designed  for  shallow  water  operations. 
Figure  6.4  is  a  picture  of  the  SonTek  ADV.  This  unit  is  currently  being  evaluated  for  use  in  the  next 
incarnation  of  the  Phoenix  AUV. 
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Figure  6.4.  Sontek  acoustic  doppler  velocimeter  (ADV; 
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D.       VIRTUAL  SIMULATION  OF  DOPPLER  SONAR 

Before  a  new  sensor  is  integrated  into  the  Phoenix  AUV  and  deployed  for  in-water  testing, 
SBD  practices  suggest  that  its  use  be  simulated  and  evaluated  first.  To  this  end  a  virtual  sensor  was 
implemented  to  represent  the  Tritech  DS30  precision  doppler  sonar.  It  was  created  to  provide  the 
same  functionality  in  the  virtual  world  as  is  expected  from  its  performance  in  the  open  ocean 
environment.  The  simulation  was  developed  in  several  steps  to  ensure  accuracy  of  each  portion  of  the 
model. 

First,  the  doppler  sonar  was  integrated  into  the  execution  level  code  in  function 
closed_loop_control_module().  In  the  sense  phase  of  the  execution  level's  sense-decide-act  loop, 
variables  were  added  to  read  the  sensor  input.  Since  the  true  hardware  is  not  present  in  the  simulation 
this  was  accomplished  by  adding  the  needed  parameters  to  the  state  vector.  The  state  vector  represents 
the  value  (or  state)  of  every  sensor  and  effector  in  the  vehicle.  This  is  the  information  that  is  sent  to 
the  dynamics  model  to  provoke  the  appropriate  forces,  or  measure  the  needed  quantities,  in  the 
surrounding  virtual  environment. 

The  next  step  included  the  addition  of  a  sensor  model  to  the  hydrodynamics  code.  This  was 
necessary  so  the  dynamics  model  might  return  proper  values  to  the  execution  level,  when  the 
execution  level  indicated  use  of  the  doppler  sonar  via  the  state  vector.  For  this  thesis  a  simple  zero- 
order  model  was  constructed.  The  value  returned  by  dynamics  is  the  true  error-free  value  of  the 
quantity  being  measured.  In  other  words,  there  is  no  error  due  to  random  noise  or  uncertainty  inserted 
in  the  response.  The  assumption  for  beginning  testing  and  evaluation  is  that  the  sensor  will  work 
exactly  as  described  by  the  technical  documentation  on  the  sensor.  Granted  this  is  not  always  a  valid 
assumption,  nonetheless  it  is  sufficient  for  initial  testing.  Random  noise  and  errors  can  easily  be 
incorporated  at  a  later  time,  since  it  is  more  appropriate  to  examine  performance  failure  modes  after 
the  sensor  had  been  proven  useful  in  the  optimal  case. 

The  final  step  for  sensor  integration  is  to  provide  a  facility  to  exercise  all  the  control  and  data 
modes  of  the  DS30.  To  accomplish  this  step,  commands  must  be  added  to  the  execution  level 
command  language.  The  device  itself  has  a  series  of  roughly  ten  commands,  ranging  from  reset  to 
designating  sampling  frequency.  During  initial  device  testing  it  is  only  necessary  to  accurately  parse 
the  output  data.  The  data  provided  by  the  unit  in  its  normal  mode  contains  both  the  unit's  speed  over 
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ground  and  the  speed  of  the  water  column.  These  values  are  all  that  is  needed  for  the  cross-body  flow 
calculation  input  to  the  vehicle  control  laws.  Thus,  implementation  of  a  full  command  language  for 
the  unit  was  deferred  as  future  work. 

The  simulation  of  the  Tritech  DS30  precision  sonar  is  a  useful  tool  for  testing  and 
development  of  robot  control  modes.  By  separating  the  process  into  well  defined  components 
researchers  are  able  to  keep  robot-specific  code  in  one  module  and  hydrodynamic  code  in  another. 
The  processes  communicate  via  a  state  vector  which  is  read  by  the  robot  execution  level  as  if  it  were 
getting  the  data  directly  from  the  actual  sensor.  This  makes  the  transition  from  the  simulation 
environment  to  the  real  world  transparent  from  the  robot's  point  of  view. 

E.       ENHANCED  CONTROL  LAWS 

The  addition  of  any  useful  sensor  is  an  iterative  process.  In  order  to  improve  vehicle  control 
the  sensor  must  be  evaluated,  prototyped,  and  integrated  into  the  existing  system.  The  Phoenix  AUV 
control  laws  are  no  exception.  These  laws  are  finely  tuned  to  provide  a  properly  damped  control 
system.  The  addition  of  a  doppler  sonar  which  can  provide  cross-body  flow  information  requires  the 
adjustment  of  these  laws  to  incorporate  (and  take  advantage  of)  the  new  information  available. 

In  order  to  use  the  information  available  from  the  doppler  sonar  unit,  it  is  necessary  to 
evaluate  which  positioning  mechanism  can  best  use  this  information.  The  question  is  primarily 
whether  to  adjust  the  control  of  the  rudders,  the  fore  and  aft  thrusters  or  both  sets  of  effectors.  In  the 
case  of  the  rudders,  which  are  primarily  used  during  forward  transit,  cross-body  flow  information  is 
not  significant.  Since  the  employment  of  this  sensor  is  envisioned  to  be  a  mechanism  which  allows 
the  AUV  to  predict  turbulent  flow  areas  before  the  entire  body  is  pushed  unstable  by  them,  rudders 
are  not  the  most  effective  control  devices.  Instead  the  virtual  cross-body  flow  sensor  is  used  for 
adjusting  thruster  control  laws. 

Thrusters  can  be  used  to  orient  the  vehicle  horizontally  and  counteract  cross-body  flow  quite 
effectively.  As  the  AUV  moves  into  a  turbulent  area  the  sensed  cross-body  flow  can  be  used  to 
activate  a  thruster  force  counteracting  the  instability  caused  by  the  turbulence.  Thus  the  thruster 
control  laws  are  adjusted  to  include  a  term  for  cross-body  flow  data.  Figure  6.5  gives  the  new  thruster 
control  law. 


-73- 


AUV_stern_lateral  =    ( -  k_thruster_psi  * 

normalize2(psi-psi_command) 

-  k_thruster_r    *  r) 

+  k_thruster_hover 

*  cross_track_distance 

-  k_thruster_current 

*  AUV_oceancurrent_x 

*  sin_psi 

+  k_thruster_current 

*  AUV_oceancurrent_y 

*  cos_psi 

+  k_sway_hover 

*  y 

+  k_thruster_current 

*  cross_body_flow_u[12]; 

Figure  6.5.  New  thruster  control  law  for  the  AUV  stern  lateral  thruster. 

This  new  control  law  can  be  written  in  two  ways:  as  a  straight  sensor  input  or  as  a  smart 
sensor.  The  straight  sensor  input  takes  the  value  sensed  by  the  doppler  sonar  and  uses  it  in  the  forward 
lateral  thruster  control  law  since  that  is  the  relative  location  of  the  physical  sensor.  A  smart  sensor  is 
one  which  "dead  reckons"  the  sensed  cross-body  flow  using  the  vehicles  recent  movement  history  and 
can  predict  the  flow  at  both  forward  and  aft  lateral  thrusters.  In  this  case  both  thrusters  can  be 
effectively  employed  to  counteract  the  turbulent  flow  encountered.  Both  of  these  control  law  options 
were  implemented  and  tested.  The  results  are  presented  in  Chapter  VII. 

The  integration  of  a  new  sensor  into  AUV  control  is  a  significant  task.  Simulation  testing 
shows  that  the  doppler  sonar  sensor  provides  useful  information  which  needs  to  be  integrated  into 
vehicle  control.  This  section  presented  an  alteration  to  the  vehicle  control  laws  for  cross-body 
thrusters  in  addition  to  two  methodologies  for  sensor  employment.  These  are  the  first  attempts  at 
harnessing  the  wealth  of  information  available  from  such  a  useful  piece  of  equipment. 

F.        SUMMARY 

The  abilities  of  the  Phoenix  AUV  to  see  the  environment  in  which  it  operates  are  limited  by  its 
sensor  suite.  Improving  the  way  the  AUV  observes  the  environment  and  increasing  sensory  input 
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provides  additional  information  for  vehicle  control  law  action.  In  order  to  thoroughly  test  the  use  of 
these  sensors,  they  must  be  integrated  into  the  execution  level  code  and  tested  in  the  target 
environment.  One  such  device  which  appears  to  greatly  improve  vehicle  control  is  a  precision  doppler 
sonar.  This  chapter  demonstrated  the  simulation  of  a  precision  doppler  sonar  and  the  integration  of  its 
output  information  into  enhanced  vehicle  control  laws.  The  results  acquired  from  simulating  such  a 
sensor  demonstrate  how  useful  the  information  is  to  AUV  control  and  the  significance  of  sensor 
simulation  in  the  vehicle  design  process. 
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VII.  SIMULATION  RESULTS 

A.  INTRODUCTION 

This  chapter  outlines  and  presents  experiments  conducted  to  validate  the  simulations 
implemented  in  this  thesis.  The  experimental  design  is  addressed  along  with  the  measures  used  to 
qualify  and  quantify  results.  Then  the  final  results  are  presented  in  concise  tables  which  are  supported 
by  plots  provided  in  Appendix  C. 

B.  DESIGN  OF  EXPERIMENTS 

When  developing  tests  to  validate  the  implemented  cross-body  flow  and  associated  AUV 
control  algorithms,  it  is  necessary  to  examine  two  areas:  the  high-resolution  buoyancy  model  with 
wave  action  effects,  and  the  flow  field  interaction  algorithm.  In  order  to  properly  test  each  area 
separate  experiments  were  designed.  Each  experiment  focuses  on  the  concerns  associated  with  the 
particular  application  being  tested. 

For  the  testing  of  the  high-resolution  buoyancy  model,  a  series  of  simple  missions  were 
conducted  under  various  sea-state  conditions.  During  these  experiments  the  Phoenix  AUV  was  placed 
on  a  base  course  heading  into  the  sea  at  a  speed  which  was  high  enough  to  allow  the  vehicle  to 
maintain  heading,  while  low  enough  to  prevent  vehicle  control  from  masking  the  effects  of  the  sea. 
The  mission  script  used  (mission. script. SeaStateTest)  is  included  in  Appendix  C. 

During  these  tests  it  was  also  necessary  to  determine  specific  factors  which  might  be  used  to 
quantify  and  qualify  the  results  that  were  found.  In  terms  of  vehicle  stability  while  heading  into  a  sea 
the  primary  factors  of  concern  are  maximum  pitch  angle  and  pitch  rate.  These  parameters  are 
appropriate  because  they  directly  indicate  the  vehicle's  stability  and  ability  to  maintain  control  as  it 
moves  through  the  seas. 

The  termination  consideration  for  these  tests  is  determination  of  what  sea  state  to  end  the 
analysis.  While  the  hydrodynamics  model  may  be  able  to  produce  a  sea  state  ranging  from  one  to 
nine,  at  some  point  the  vehicle  becomes  so  unstable  that  its  presence  is  not  worthwhile.  Thus  the 
analysis  range  from  minimal  sea  states  (1)  to  a  sea  state  in  which  the  vehicles  stability  was  in 
questionable  for  greater  than  50%  of  the  run. 
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In  the  first  group  of  experiments,  the  high-resolution  buoyancy  model  is  tested  in  sea  states 
ranging  from  one  to  a  sea  in  which  the  vehicle  does  not  maintain  stability.  During  each  exercise  the 
AUV  proceeded  on  a  course  directly  into  the  sea  at  a  speed  high  enough  to  maintain  steerage.  These 
runs  fully  exercised  the  high  resolution  buoyancy  model  and  the  wave  motion  simulation.  The 
experiments  are  designated  SS.l  through  SS.5  corresponding  to  sea  states  one  through  five. 

The  second  set  of  experiments  are  aimed  at  testing  the  flow-field  simulation  and  vehicle 
control  using  cross-body  flow  sensor  input.  The  goal  is  to  bracket  the  torpedo  tube  docking  problem 
by  running  experiments  in  flow  conditions  which  ranged  from  lower  than  expected  turbulence  levels 
to  well  above  expected  turbulence  levels.  Additionally,  the  results  with  the  cross-body  sensor 
available  are  compared  to  runs  with  the  sensor  absent.  Table  7.1  shows  the  naming  convention  for  all 
of  the  experiment  variations. 


No  Flow  Field 

Normal  Flow  Field 

Extreme  Flow  Field 

No  Flow  Sensor 

Experiment  CBF.  1 

Experiment  CBF.  2 

Experiment  CBF.  3 

Flow  Sensor 

Experiment  CBF.4 

Experiment  CBF.  5 

Experiment  CBF.  6 

Smart  Control  Sensor 

Experiment  CBF.7 

Experiment  CBF. 8 

Experiment  CBF.9 

Table  7.1.  Variation  of  conditions  for  experimental  cross-body  flow  (CBF)  missions. 

While  running  the  CBF  missions,  three  criteria  were  chosen  to  quantify  observed  results: 
vehicle  distance  from  track,  time  to  regain  track  in  turbulence  and  whether  or  not  the  vehicle  collided 
with  the  submarine  hull  during  the  docking  mission.  These  parameters  are  appropriate  because  they 
directly  address  AUV  survivability  during  torpedo  tube  recovery.  If  flow  perturbations  cause 
significant  variance  from  the  preplanned  track,  then  AUV  endurance  and  control  become  a  concern.  If 
collision  occurs,  then  safety  of  the  AUV  and  the  submarine  become  significant.  Thus  these  metrics 
provide  a  useful  measure  of  AUV  performance  in  the  presence  of  turbulent  flow.  In  each  run  the 
commanded  path  was  identical,  as  specified  by  the  mission  script  mission.script.FlowFieldTestLoop 
included  in  Appendix  C. 

The  combined  results  of  these  experiments  provide  a  sound  measure  of  the  algorithms 
developed  in  this  thesis.  They  address  the  performance  of  the  high-resolution  buoyancy  model,  the 
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wave  motion  simulation,  the  turbulent  flow  field  simulation,  and  the  cross-body  flow  sensor  control 
algorithm.  These  simulation  experiments  also  serve  to  illustrate  the  accuracy  of  the  physically  based 
models  they  are  derived  from.  Any  errors  in  a  cross-coupled  model  as  complex  as  vehicle  dynamics 
will  almost  certainly  cause  vehicle  instability  in  the  virtual  environment. 

C.       RESULTS 

The  experiments  described  in  the  previous  section  were  conducted  ising  the  Phoenix  AUV 
execution  level  and  the  C++  implementation  of  the  virtual  environment.  The  results  were  measured  in 
terms  of  the  metrics  discussed,  collected  in  the  form  of  parameter  graphs  included  in  Appendix  C  and 
summary  tables  presented  in  this  chapter. 

The  experiment  which  exercised  the  high-resolution  buoyancy  model  and  the  wave  motion 
simulation  provided  interesting  results.  The  vehicle  was  able  to  maintain  stability  in  sea  states  ranging 
from  zero  to  five.  In  sea  state  five  the  vehicle  was  unstable  for  roughly  60%  of  the  5  minutes  that  the 
run  lasted.  Nevertheless,  the  control  algorithms  were  able  to  maintain  a  relatively  stable  attitude  while 
the  vehicle  was  moved  by  large  wave  swells.  Vehicle  pitch  rate  and  maximum  pitch  angle  varied 
greatly  between  sea  states  as  expected.  Table  7.2  contains  the  data  addressing  these  metrics.  Worth 
noting  is  the  dramatic  increase  in  pitch  rate  and  pitch  angle  when  the  sea  state  progressed  from  four  to 
five.  It  is  likely  that  shorter  sampling  rates,  modified  control  coefficients  and  the  predictive  control 
algorithm  specified  in  (Riedell,  Healey,  1998)  can  improve  performance  even  further.  Surprisingly  the 
vehicle  was  able  to  maintain  control  in  sea  states  well  above  what  was  expected.  Further  in-water 
testing  is  definitely  needed  to  validate  these  results. 


Experiment 

SS.l 

SS.2 

SS.3 

SS.4 

SS.5 

Pitch  rate 
(deg/sec) 

0.2 

1.0 

1.5 

4.5 

11.0 

Maximum 

pitch  angle 

(deg) 

0.35 
(0.15  avg) 

1.0 
(1.0  avg.) 

3.0 

(1.5  avg.) 

7.0 
(4.5  avg) 

40.0 
(11.0  avg.) 
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Approximate 

0% 

0% 

1  % 

15% 

60% 

amount  of 

time  vehicle 

was  unstable 

Table  7.2.  Experimental  results  of  AUV  stability  in  various  sea  states. 

The  results  from  the  experiment  which  tested  vehicle  control  in  the  flow  field  are  also 
significant.  For  the  most  part  the  results  are  as  expected.  The  first  metric  used,  collision  with  the  hull, 
gives  a  boolean  result  for  each  run.  Table  4.3  contains  the  data  collected  for  runs  under  all  of  the 
various  conditions.  In  the  no  flow  and  normal  flow  conditions,  vehicle  control  was  stable  enough  to 
prevent  the  AUV  from  colliding  with  the  submarine  hull.  In  the  extreme  flow  case  the  AUV  collided 
with  the  hull  in  every  case,  regardless  of  sensor  control.  The  point  at  which  collision  occurred  was  at 
the  pump  suction  inlet  along  the  hull.  In  the  extreme  case  the  suction  flow  simulates  a  flow  of  1.3 
knots  vice  1.0  knot  in  the  normal  flow  case.  This  slight  increase  in  flow  force  creates  a  significant 
problem  for  AUV  control.  Despite  flow  turbulence  near  the  torpedo  tube  door,  no  collisions  occured 
in  the  door  area. 


Flow  Regime 

No  Sensor 

Simple  Control  Sensor 

Smart  Control  Sensor 

No  Flow 

CBF.l:  No  Collision 

CBF.2:  No  Collision 

CBF.3:  No  Collision 

Normal  Flow  Profile 

CBF.4:  No  Collision 

CBF.5:  No  Collision 

CBF.6:  No  Collision 

Extreme  Flow  Profile 

CBF.7:  Collision  at 
pump  suction  only 

CBF.8:  Collision  at 
pump  suction  only 

CBF.9:  Collision  at 
pump  suction  only 

Table  7.3.  Cross-body  flow  (CBF)  experimental  results  of  AUV  collision  with  submarine  hull. 

The  other  measures  evaluated  are  the  overall  distance  the  vehicle  departed  from  its  pre- 
planned track  due  to  turbulent  flow  and  how  long  it  took  to  return  to  track  after  departure.  Departure 
from  track  was  measured  in  the  most  turbulent  areas  within  the  flow  field:  the  pump  suction,  pump 
discharge,  and  torpedo  tube  door  docking.  Table  7.4  presents  the  results  of  these  measures  at  the  three 
points  for  each  experiment.  These  results  are  as  expected  when  moving  from  one  flow  condition  to 
another.  Yet  the  results  within  each  condition  show  that  the  cross-body  flow  sensor  input  to  thruster 
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control  has  no  significant  effect  on  distance  from  track,  but  does  aid  in  the  time  needed  to  get  back  on 
base  course.  The  lower  return  times  are  most  likely  due  to  the  fact  that  the  thrusters  are  helping  to 
stabilize  the  vehicle  when  the  cross-body  flow  sensor  is  used.  More  accurate  testing  of  the  adjusted 
control  laws  is  needed.  Nevertheless,  the  control  results  are  promising.  The  additional  sensor  does  in 
fact  provide  some  additional  thruster  control  ability.  It  is  left  to  future  researchers  to  implement  a 
more  effective  control  law. 


Flow  Condition 

Position 

No  Sensor 

Simple  Control 
Sensor 

Smart  Control 
Sensor 

No  Flow 

Distance  from  track  at 
pump  discharge  (feet) 

0 

0 

0 

No  Flow 

Time  to  regain  track 
(seconds) 

0 

0 

0 

No  Flow 

Distance  from  track  at 
pump  suction  (feet) 

0 

0 

0 

No  Flow 

Time  to  regain  track 
(seconds) 

0 

0 

0 

No  Flow 

Distance  from  track  at 

torpedo  tube  entry 

(inches) 

0 

0 

0 

No  Flow 

Time  to  regain  track 
(seconds) 

.    0 

0 

0 

Normal  Flow 
Profile 

Distance  from  track  at 
pump  discharge  (feet) 

13 

13 

13 

Normal  Flow 
Profile 

Time  to  regain  track 
(seconds) 

55 

52 

45 

Normal  Flow 
Profile 

Distance  from  track  at 
pump  suction  (feet) 

5 

5 

5 

Normal  Flow 
Profile 

Time  to  regain  track 
(seconds) 

44 

43 

40 

Normal  Flow 
Profile 

Distance  from  track  at 

torpedo  tube  entry 

(inches) 

8.7 

6.5 

6.0 
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Normal  Flow 
Profile 

Time  to  regain  track 
(seconds) 

N/A 

N/A 

N/A 

Extreme  Flow 
Profile 

Distance  from  track  at 
pump  discharge  (feet) 

18 

18 

18 

Extreme  Flow 
Profile 

Time  to  regain  track 
(seconds) 

60 

57 

56 

Extreme  Flow 
Profile 

Distance  from  track  at 
pump  suction  (feet) 

10 

10 

10 

Extreme  Flow 
Profile 

Time  to  regain  track 
(seconds) 

47 

44 

42 

Extreme  Flow 
Profile 

Distance  from  track  at 

torpedo  tube  entry 

(inches) 

10.3 

9.6 

8.7 

Extreme  Flow 
Profile 

Time  to  regain  track 
(seconds) 

N/A 

N/A 

N/A 

Table  7.4.  AUV  distance  from  track  under  various  cross-body  flow  (CBF)  experiment  conditions. 

The  results  arrived  at  in  these  experiments  provide  useful  insight  into  the  algorithms 
implemented  in  this  thesis.  The  high-resolution  buoyancy  model,  the  wave  motion  simulation  and  the 
turbulent  flow  field  simulation  appear  to  be  accurate  and  give  consistent  results  which  are  in  line  with 
expectations.  On  the  other  hand,  the  experiments  also  demonstrate  that  the  control  algorithms  which 
use  doppler  sonar  input  for  cross-body  flow  measurement  need  to  be  tuned.  The  virtual  environment 
thus  provides  a  useful  tool  for  control  law  testing,  which  can  be  further  improved  by  incorporation  of 
results  from  in-water  validation  tests. 

D.       SUMMARY 

Experiments  are  a  useful  tool  in  any  researcher's  repertoire.  They  serve  to  verify  the  theories 
upon  which  technological  innovations  are  based.  This  chapter  presents  the  design  of  experiments  that 
are  performed  in  simulation  and  used  to  test  the  models  developed  in  this  thesis.  The  experiments 
address  testing  of  the  high-resolution  buoyancy  model,  the  wave  motion  simulation,  turbulent  flow- 
field  simulation,  and  enhanced  vehicle  control  using  a  doppler  sonar  employed  as  a  cross-body  flow 
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sensor.  Additionally,  design  of  experiments  and  the  metrics  used  to  measure  results  are  discussed  to 
provide  the  reader  with  a  good  understanding  of  what  success  is  based  on.  These  experiments  are  a 
useful  means  to  rigorously  test  the  Phoenix  AUV  dynamics  model.  The  simulation  results  give  hard 
data  demonstrating  the  stability  and  accuracy  of  the  hydrodynamics  model  and  associated  cross-body 
flow  control  laws. 
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VIII.  CONCLUSIONS  AND  RECOMMENDATIONS 

A.  CONTEXT 

This  thesis  has  taken  an  in-depth  look  at  methods  of  modeling  environmental  effects  in  a 
virtual  environment.  The  net  result  is  a  virtual  environment  for  the  NPS  Phoenix  AUV  which  is  more 
robust  and  better  simulates  the  environment  for  which  the  AUV  is  being  designed.  These 
improvements  are  aimed  at  enhancing  the  SBD  process,  allowing  engineers  to  rigorously  test  the 
performance  of  AUV  systems  prior  to  deployment  in  the  vehicle. 

B.  RESEARCH  CONTRIBUTIONS  AND  CONCLUSIONS 

Throughout  this  thesis  the  intention  has  been  to  provide  solutions  to  real-world  problems. 
With  that  in  mind,  even  simulation  results  provide  useful  contributions  to  the  modeling  community 
along  with  interesting  experimental  results  for  those  concerned  with  autonomous  robot  simulation. 
The  simulation  enhancements  include  a  high-resolution  buoyancy  model  for  wave  simulation,  an 
extensible  body-induced  flow  methodology,  and  an  approach  to  platform-independent  distributed 
simulation  environments. 

The  high-resolution  buoyancy  model  divides  the  modeled  vehicle  into  fifteen  separate 
sections.  Each  one  is  then  evaluated  for  its  contribution  to  the  overall  vehicle  buoyancy.  This 
approximation  gives  an  accurate  representation  of  vehicle  posture  at  shallow  depths  in  various  sea 
states.  It  proved  to  be  quite  useful  when  evaluating  vehicle  operation  in  various  broach  postures.  Once 
fully  submerged,  at  a  depth  where  no  portion  of  the  vehicle  is  consistently  exposed,  its  more  accurate 
modeling  characteristics  were  less  apparent,  again  as  expected.  The  high-resolution  buoyancy  model 
is  a  needed  improvement  with  no  noticeable  consequence  in  terms  of  real-time  performance. 

The  ability  to  test  AUV  control  in  various  sea  states  also  turned  out  to  be  a  significant 
improvement  in  vehicle  modeling.  The  effects  of  wave  motion  come  into  play  in  shallow-water 
operations  as  well  as  during  submarine  docking  evolutions.  At  shallow  the  forces  of  wave  motion 
cause  changes  in  vehicle  velocities,  accelerations  and  buoyancy.  These  factors  need  to  be  considered 
when  fine-tuning  control  algorithms.  They  bring  to  light  possibilities  of  over-sensitve  control  laws 
which  can  cause  vehicle  hunting  and  instability.  During  docking  evolutions  at  submarine  periscope 
depth,  wave  movement  is  also  a  factor.  Although  increasing  depth  for  this  type  of  operation  reduces 
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wave-induced  forces,  they  are  still  present  and  need  to  be  dealt  with. 

Another  improvement  in  functionality  of  the  virtual  environment  is  the  ability  to  simulate 
body-induced  flow  forces.  The  methodology  used  for  this  simulation  is  completely  extensible.  As 
researchers  desire  to  change  flow  conditions,  a  simple  data  file  replacement  can  import  the  new  flow 
field  into  the  virtual  environment.  By  bracketing  the  submarine  docking  problem  with  worst-case  and 
best-case  flow  instability,  simulation  results  indicate  that  a  feasible  solution  exists.  A  slight 
modification  to  current  torpedo  tube  door  mechanisms  might  thus  provide  an  avenue  to  AUV 
recovery  by  naval  submarines. 

The  use  of  a  doppler  sonar  to  determine  cross-body  flow  is  also  evaluated.  This  type  of  sensor, 
having  the  ability  to  provide  speed  over  ground  or  speed  through  the  water,  enabled  enhanced  AUV 
control  in  complex  flow  fields.  Its  employment  allows  the  robot  to  predict  and  compensate  for 
movement  instability  using  real-time  flow  condition  feedback.  Initial  evaluation  of  doppler  sonar 
demonstrates  that  the  sensor,  when  properly  used,  provides  irreplaceably  valuable  inputs  for  vehicle 
control. 

Finally,  this  thesis  shows  that  platform-independent  3D  real-time  simulations  are  possible. 
The  use  of  platform-neutral  programming  languages  coupled  with  the  rapidly  increasing  performance 
of  personal  computers  has  brought  the  ability  to  run  complex  distributed  simulations  anytime, 
anywhere.  As  network  bandwidth  continues  to  improve  and  PC  performance  is  enhanced,  platform- 
independent  simulations  will  continue  to  get  better  and  become  more  popular. 

C.       RECOMMENDATIONS  FOR  FUTURE  WORK 

On  the  technological  frontier  there  are  always  things  to  do.  Breakthroughs  in  technology 
happen  at  an  amazing  rate,  with  each  new  discovery  bringing  a  new  piece  of  gear  or  programming 
paradigm  to  light.  As  these  developments  occur  it  will  continue  to  be  necessary  to  thoroughly  test  and 
evaluate  new  technologies.  The  virtual  environment  is  the  ideal  place  for  testing  potential  AUV 
hardware  and  software. 

This  thesis  falls  short  in  the  test  and  evaluation  of  the  modeling  technology  proposed  due  to 
the  lack  of  in-water  tests.  To  remedy  this  situation,  a  series  of  tests  need  to  be  conducted  to  validate 
both  the  wave  model  and  the  complex  body-induced  flow  interaction  algorithm.  These  additions  to 
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the  virtual  environment  provide  exceptional  insight  into  vehicle  behavior,  but  these  results  need  not 
be  broadly  accepted  until  all  doubt  is  laid  to  rest  through  validating  in-water  tests. 

Another  area  for  future  consideration  involves  both  the  execution  level  code  and  the  dynamics 
code.  The  current  versions  of  these  programs  use  standard  British  units.  Yet  the  DIS  protocol  requires 
metric  units  in  its  broadcast  standard.  This  difference  caused  some  inaccurate  results  during  the 
prototyping  stages.  In  some  cases  formulations  appeared  to  be  correct  but  unit  differences  caused 
erroneous  results.  After  extensive  troubleshooting  all  units  were  corrected  and  the  results  verified.  For 
future  development  a  single  set  of  units  (metric  since  DIS  requires  it)  needs  to  be  implemented  in 
both  the  execution  level  code  and  the  dynamics  code. 

This  thesis  also  proposes  that  a  doppler  sonar  be  used  as  a  cross-body  flow  indicator  onboard 
the  Phoenix  AUV.  The  simulation  model  for  the  doppler  sensor  used  in  this  thesis  was  a  simple  one, 
lacking  any  noise  distribution.  Nonetheless,  simulation  of  such  a  sensor  demonstrates  it  can  provide 
significant  control  enhancements.  Further  work  is  needed  in  simulation  enhancement.  Comparisons 
need  be  made  between  perfect  data  and  expected  (noisy)  real-world  data.  As  the  NPS  AUV  research 
group  moves  towards  the  third  incarnation  of  the  Phoenix  AUV  it  will  be  interesting  install  and  test 
the  DS30  doppler  sonar.  An  instrument  of  this  nature  will  likely  enable  very  precise  control  of  the 
robot  in  dangerous  operating  environments. 

Another  useful  extension  for  robot  development  will  be  the  integration  of  a  depth-sensing 
model  coupled  with  real-world  terrain  topology  (Leaver,  1998).  It  is  also  useful  to  move  the  virtual 
world  into  the  domain  of  testing  sensor  and  effector  performance  in  various  acoustic  environments. 
This  is  a  significant  step  forward  from  the  generic  environment  testing  currently  performed,  enabling 
researchers  to  test  equipment  in  a  virtual  Monterey  Bay,  then  test  in  the  real  bay.  It  will  likely 
eliminate  errors  normally  attributed  to  environmental  considerations. 

Other  sensors  to  be  enhanced  in  virtual  simulation  are  the  ST725  and  ST  1000  sonars.  These 
sonars  were  modeled  using  several  scan  modes,  employed  in  numerous  different  execution  level 
tactics  by  (Davis,  1996).  While  the  modes  are  accessible  to  all  for  low-level  control,  a  simplification 
is  required  allowing  for  easier  scan  mode  selection.  Addition  of  manual  steering  along  a  true  bearing 
during  the  final  stages  of  thesis  testing  added  a  new  sensor  value:  lateral  range  (and  range  rate)  to  the 
submarine  maintaining  steady  course  and  speed.  An  enumeration  of  all  sonar  modes  and  their  addition 
to  the  execution  command  language  will  be  useful  in  future  tactic  development. 
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Animation  is  a  vital  part  of  any  virtual  environment  simulation.  Helping  humans  visualize  the 
interactions  taking  place  in  the  environment.  It  is  one  of  the  key  reasons  virtual  simulations  are  even 
created.  The  Phoenix  AUVs  virtual  environment  is  an  irreplaceable  resource.  Continued  use  of  virtual 
environment  visualization  and  experimental  validation  will  continue  to  provide  invaluable  insight. 
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APPENDIX  A.  VIRTUAL  ENVIRONMENT  C++  CODE 


1.  UUVBody.C  Excerpt 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
/* 

Program:  UUVBody.C 

Description:        Six  degree-of -freedom  underwater  vehicle  hydrodynamics 
based  on  Healey  model 


Revised: 
System: 
Compiler: 
Compilation: 


Author : 


EOM  Revisions: 


Dissertation: 


Advisors : 
References : 


24  February  98 

Irix  5.3 

ANSI  C++ 

irix>  make  UUVBody.o 

irix>  CC  UUVBody.C  -lm  -c  -g  +w 

-c  ==  Produce  binaries  only,  suppressing  the  link  phase, 
+w  ==  Warn  about  all  questionable  constructs. 


Don  Brutzman 

Code  UW/Br 

Naval  Postgraduate  School 

Monterey  CA  93943-5000 


brutzman@nps .navy.mil 

408.656.2149  work 
408.656.3679  fax 


Jeff  Riedel,  FEB  97:   removed  extra  cross-body  flow  terms 
Kevin  Byrne,  FEB  98:   high-resolution  buoyancy,  cross-body  flow 
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School,  Monterey  California,  December  1994.   Available  at 
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for  an  Autonomous  Underwater  Vehicle,  technical  report 
NPS-CS-010-94,  Naval  Postgraduate  School,  Monterey 
California,  December  1994.   The  accompanying  public 
electronic  distribution  of  this  reference  includes  source 
code  and  executable  programs.   World-Wide  Web  (WWW) 
Uniform  Resource  Locator  (URL)  is 
http: //www. stl .nps .navy.mil/~auv 
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Postgraduate  School,  Monterey  California,  September  1996. 


Status : 


Fossen,  Thor  I.,  _Guidance  and  Control  of  Ocean  Vehicles_, 
John  Wiley  and  Sons,  Chichester  England,  1994. 

Bacon,  Daniel  Keith,  Jr.  "Integration  of  a  Submarine  into 
NPSNET, "  Master's  Thesis,  Naval  Postgraduate  School, 
Monterey,  California,  September  1995.   Available  via 
http: //www.npsnet .nps .navy.mil/npsnet/publications .html 

Equations  of  motion  tested  satisfactorily, 

verification  against  in-water  tests  remains. 

Added  buoyancy  and  center-of-buoyancy  changes  at  surface 
based  on  Dan  Bacon's  thesis  work. 

Housekeeping:  move  utilities  to  math_utilities .c 


Future  work: 


Comments  and  suggestions  are  welcome! 


*/ 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

//*******  Excerpt  Follows  ********// 


//- 


■II 


void  UUVBody: :  integrate_equations_of_motion  () 
{ 

int  MAX_ACCELERATIONS_EXCEEDED  =  FALSE; 

current_uuv_time  =  AUV_time; 


double  dt 


=  current_uuv_time  -  time_of_posture_value  (.)  ; 

//  mission  clock  was  reset,  rezero  the  dynamics  model 


if  (dt  <  0.0) 
{ 

current_uuv_time    =  AUV_time; 

set_time_of_posture  (AUV_time) ; 

set_velocities     (0.0,  0.0,  0.0,  0.0,  0.0,  0.0); 

set_accelerations  (0.0,  0.0,  0.0,  0.0,  0.0,  0.0); 

dt  =  0.0; 


u 

=  0.0 

V 

=  0.0 

w 

=  0.0 

p 

=  0.0 

Q 

=  0.0 

R 

=  0.0 

} 

double 

rho2 

=  rho 

/  2.0; 

double 

L2 

=  L  * 

L; 

double 

L3 

=  L  * 

L  *  L; 

double 

L4 

=  L  * 

L  *  L  *  L; 

double 

L5 

=  L  * 

L  *  L  *  L 

//  note  that  sign  is  not  preserved  in  the  following  squared  variables 
//       in  order  to  present  consistent  naming  with  Healey  reference  paper. 
//       To  preserve  sign,  use  (U  *  fabs  (U) )  etc. 
double  P2        =  P  *  P; 


double  Q2 
double  R2 
//  double  U2 
double  V2 
double  W2 


=  Q  *  Q 

=  R  *  R 

=  U  *  U 

=  V  *  V 

=  W  *  W 


-90- 


//  calculate  world  coordinate  posture  rates,  use  holding  variables  for  speed 


double  PHI 
double  THETA 
double  PSI 


=  phi_value  ( ) 
=  theta_value  () 
=  psi_value    () 


double 

sinPHI 

=  sin 

PHI  ) 

double 

cosPHI 

=  cos 

PHI  ) 

double 

sinTHETA 

=  sin 

THETA  ) 

double 

COSTHETA 

=  cos 

THETA  ) 

double 

sinPSI 

=  sin 

PSI  ) 

double 

cosPSI 

=  cos 

PSI  ) 

//  clamp  inputs  to  max  values  allowed  in  hydrodynamics  coefficients  file 
if  (MAX_RPM  >  0.0) 


// 


clamp  (&  AUV_port_rpm,  -MAX_RPM, 
clamp  (&  AUV_stbd_rpm,  -MAX_RPM, 

} 

if  (MAX_PLANE  >  0.0) 

{ 


MAX_RPM, 
MAX_RPM, 


"AUV_port_rpm" ) ; 
"AUV_stbd_rpm" ) ; 


clamp  (&  AUV_delta_planes,  -radians  (MAX_PLANE) ,   radians  (MAX_PLANE) , 
"AUV_delta_planes " ) ; 
} 

i  f  ( MAX_RUDDER  >  0.0) 
{ 

clamp  (&  AUV_delta_rudder,  -radians  (MAX_RUDDER) ,  radians  (MAX_RUDDER) , 
"AUV_delta_rudder" ) ; 
} 

if  (MAX_THRUSTER  >  0.0) 
{ 
clamp(&  AUV_bow_lateral ,    -MAX_THRUSTER,MAX_THRUSTER, "AUV_bow_lateral" ) ; 
clamp(&  AUV_stern_lateral,  -MAX_THRUSTER,MAX_THRUSTER, " AUV_stern_lateral " ) ; 
clamp (&  AUV_bow_vertical,   -MAX_THRUSTER,MAX_THRUSTER, " AUV_bow_vertical " ) ; 
clamp  (&  AUV_stern_vertical, -MAX_THRUSTER,MAX_THRUSTER, "AUV_stern_vertical" ) ; 
} 


//  finish  initializations 
double  delta_planes_stern 
double  delta_planes_bow 
double  delta_rudder_stern 
double  delta  rudder  bow 


// 


AUV_delta_planes ; 

-  AUV_delta_planes; 
AUV_delta_rudder ; 

-  AUV  delta  rudder; 


//  Zero  ordered  thruster  values  if  no  thrusters  present 
AUV_bow_lateral    *=  THRUSTERS; 
AUV_stern_lateral  *=  THRUSTERS; 
AUV_bow_vertical   *=  THRUSTERS; 
AUV_stern_vertical*=  THRUSTERS; 

//  double  EPSILON    =  epsilon  ();  //  no  longer  used  in  revised  model 

//**************************plag  for  wave  Model 

//Moved  Variable  definition  for  visibility  throughout  both  models 

double   sway_integral  =  0.0; 

double  heave_integral  =  0.0 

double  pitch_integral  =  0.0 

double   yaw_integral  =  0.0 

double   roll_integral  =  0.0 

double  surge_integral  =  0.0 

double  U_cf_x; 


i  f  ( WAVE_BOUYANCY_MODEL 


0)   { 
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// // 

//  calculate  neutral  buoyancy  using  center  of  buoyancy  near  surface  ---II 

if       (AUV_z  <=  H  /  2.0)  /*  transition,  calculate  broach  extent  */ 

{ 

if    (AUV_z  >=  - (H  /  2.0))        /*  broach  region,  reduce  buoyancy       */ 

revisedBuoyancy  =  Buoyancy  *  (AUV_z  +  H/2.0)/  H; 

else  revisedBuoyancy  =0.0;       /*  completely  out  of  the  water         */ 
} 
else     revisedBuoyancy  =  Buoyancy;  /*  >  H/2,  no  broach,  normal  submerged   */ 


This  picture  shows  the  condition  (AUV_z  ==  H  /  2.0)  which  is  the 
transition  point  above  which  revisedBuoyancy  begins  to  drop  off. 

revisedBuoyancy  will  =  0  when  (AUV_z  <=  -  H  /  2.0) 

Severe  buoyancy  changes  result  when  AUV  position  magically  begins 
at  depths  so  shallow  that  the  AUV  is  initially  above  the  surface, 
-z 


-  H 

-  H/2 

0    surface 


I  (I.  \ 

+  +  H/2  (  |  AUV_z  =  +  H/2  |  \  0 

I  (  /  0 

+  +H  (| \l 

I 

+  z 

depth  down  (positive  increasing  z) 


//  if  boat  is  broaching  and  pitch  THETA  is  positive,  perform  an  approximate 
//  calculation  of  how  center  of  buoyancy  CB  moves  back  towards  stern 

//  nose_length  is  defined  in  UUVmodel.H  and  stays  fixed 

if       ((THETA  ==0.0)  ||  (AUV_z  >=  H  /  2.0)) 
{ 

revised_x_B   =  x_B;  //  prevent  divide-by-zero  case  and  too-deep  case 
) 

else  if  (THETA  >  0.0) 
{ 

surface_length  =  AUV_z  /      sinTHETA; 
} 

else  if  (THETA  <  0.0) 
{ 

surface_length  =  AUV_z  /  (-  sinTHETA)  ,-  //  roughly  symmetric  fore+aft 
} 

else 
{ 

cout  <<  "Unexpected  case  in  revised  CB  calculation!"  <<  endl; 

revised_x_B   =  x_B;  //  prevent  divide  by  zero  case 
) 
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if  ( (THETA  !-  0.0)  &&  ( surf ace_length  <  nose_length)  &&  (AUV_z  <=  H  /  2.0)) 

//  move  x_CB  aft  (fwd)  but  only  if  nose  (stern)  broaches  the  surface 

{ 

revised_x_B   =  x_B  -  (nose_length  -  surface_length)  *  sinTHETA  /  2.0; 
} 

if  (TRACE  ||  TRACE_EOM  |   ( revisedBuoyancy  !=  Buoyancy)) 
{ 

cout  <<  "revisedBuoyancy  =  "  <<  revisedBuoyancy  <<  ",  " ; 

cout  <<  "Weight  =  "          <<  Weight  <<  " ,  " ; 

cout  <<  endl; 

cout  <<  "  surface_length  =  "   <<  surface_length  <<  " ,  " ; 

cout  <<  "nose_length  =  "      <<  nose_length  <<  " ,  " ; 

cout  <<  "revised_x_B  =  "      <<  revised_x_B  <<  endl ; 
} 
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II    integrate  drag  forces  over  the  vehicle  ----------------  -// 

//  corresponding  to  cross-body  flow.   Use  cross-sectional  slices.  -  -  -  -  -// 

double  dx; 

//  traverse  longitudinal  centerline:   index  through  x  coordinate  arrays 

for  ( int  x_index  =  0;  x_index  <  cross_sections-l;  x_index  ++) 

{ 

dx  =  fabs  (xx  [x_index]  -  xx  [x_index  +  1] ) ; 

U_cf_x  =  sqrt  (   square  (V  +  xx  [x_index]  *  R) 

+  square  (W  -  xx  [x_index]  *  Q)  )  ; 

if  (U_cf_x  >  1.0E-6)  //  arbitrary  small  non-0  minimum 
{ 

sway_integral   +=    rho2  *  (  C_dy  *  hh  [x_index] 

*  square  ( (V  +  xx  [x_index]  *  R) )  ) 

//  removed  from  model  +  C_dz  *  bb  [x_index] 

//  *  square  ( (W  -  xx  [x_index]  *  Q) ) ) 

*  (V  +  xx[x_index]  *  R)  *  dx  /  U_cf_x; 


heave_integral  +=    rho2  *  ( 

//  removed  from  model  C_dy  *  hh  [x_index] 

//  *  square  ( (V  +  xx  [x_index]  *  R) ) 

+  C_dz  *  bb  [x_index] 

*  square  ( (W  -  xx  [x_index]  *  Q) ) ) 

*  (W  -  xx  [x_index]  *  Q)  *  dx  /  U_cf_x; 

pitch_integral  +=    rho2  *  ( 

//  removed  from  model  C_dy  *  hh  [x_index] 

//  *  square  ( (V  +  xx  [x_index]  *  R) )  ) 

+  C_dz  *  bb  [x_index] 

*  square  ( (W  -  xx  [x_index]  *  Q) ) ) 

*  (W  -  xx  [x_index]  *  Q) 
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//  *  note  sign  correction 
*  xx  [x_index]  *  dx  /  U_cf_x; 


yaw_integral  += 


//  removed  from  model 

// 


} 
} 

if  (TRACE  | |  TRACE_EOM) 
{ 


rho2  *  (  C_dy  *  hh  [x_index] 

*  square  ( (V  +  xx  [x_index]  *  R) )  ) 

+  C_dz  *  bb  [x_index] 

*  square  ( (W  -  xx  [x_index]  *  Q) ) ) 

*  (V  +  xx  [x_index]  *  R) 

*  xx  [x_index]  *  dx  /  U_cf_x; 


cout 

<< 

<< 

cout 

<< 

<< 

cout 

<< 

<< 

cout 

<< 

<< 

dx  =  "  <<  dx  <<  " ,  U_cf_x  =  "  <<  U_cf_x 

,  sway_integral   =  "  <<  sway_integral  <<  endl; 

dx  =  "  <<  dx  <<  " ,  U_cf_x  =  "  <<  U_cf_x 

,  heave_integral  =  "  <<  heave_integral  <<  endl; 

dx  =  "  <<  dx  <<  " ,  U_cf_x  =  "  <<  U_cf_x 

,  pitch_integral  =  "  <<  pitch_integral  <<  endl; 

dx  =  "  <<  dx  <<  " ,  U_cf_x  =  "  <<  U_cf_x 

,  yaw_integral    =  "  <<  yaw_integral  <<  endl; 


}   //  end  old  bouyancy  model 

else  if  (WAVE_BOUYANCY_MODEL  ==  TRUE)   { 

int     in_sub_f low_f ield  =  0; 

int     pw_f lowf ield_x [cross_sections] ; 

int    pw_f lowf ield_r [cross_sections] ; 

//required  variables  for  piecewise  calculations  of  wave  motion  effects 
double  pw_AUV_x[cross_sections] ; 
double  pw  AUV  y[ cross  sections] ; 
double  pw_AUV_z [cross_sections] ; 
double  pw_nose_length[cross_sections] ; 
double  pw_surface_length[cross_sections] ; 
double  pw_dx[cross_sections] ; 
double  pw_revised_x_B [cross_sections] ; 
double  pushup [cross_sections] ; 
double  pw_revisedBouyancy [cross_sections] ; 
double  x_dif ference; 
double  y_dif ference; 
double  z_dif ference; 
double  AUV_TTube_z_dif ference; 
double  AUV_SUB_Course_dif ference  =  0.0; 
double  grid_x_dif ference  -    0.0; 
double  grid_r_dif ference  =  0.0; 
double  f low_force_direction[cross_sections] ; 

double  K_waves  =  0.4;       //This  is  a  factor  used  to  reduce  wave  effects.  Otherwise 
vehicle  goes  unstable. 

double  temp_doppler_stw_u  =  0.0; 
double  temp_doppler_stw_v  =  0.0; 


Vector3D  U_waves [cross_sections]  ; 
Vector3D  pw_UVW; 
reference 


//Holds  piecewise  flow  velocities  in  AUV  frmae  of 
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Vector3D  f low_force_magnitude [cross_sections] ;     //This  holds  x-dot,  y-dot,  z-dot  in 
sub  ref  frame 

Hmatrix  f low_rotation_matrix;  //This  is  used  to  move  flow  vector  from 

the  sub's  (ft/sec) 

//Additions  to  the  equations  of  motion 
double  f low_f ield_sway_integral  =  0.0 
double  f low_f ield_surge_integral  =  0.0 
double  f low_f ield_heave_integral  =  0.0 
double  f low_f ield_roll_integral  =  0.0 
double  f low_f ield_pitch_integral  =  0.0 
double  f low_f ield_yaw_integral    =  0.0 

if  (SUBMARINE_DOCKING  ==  TRUE)   { 

//Check  to  se  if  AUV  is  in  the  influence  field  of  the  submarine 
//This  conversion  uses  0.3048  meters  per  foot  or  3.281  ft  per  meter 
x_difference  =  (AUV_x  -  submarine_x) 
y_difference  =  (AUV  y  -  submarine_y) 
z_difference  =  (AUV_z  -  submarine_z) 

//The  order  of  AUV  and  TT  is  reversed  to  get  sign  correct  since  +z  is  down 
AUV_TTube_z_dif ference  =  torpedotube_z  -  AUV_z; 

//All  box  calculations  are  in  feet,  here  we  convert  to  meters  and 

//then  compare 

//The  15in  y   calc  accounts  for  sub  diameter  of  30  ft,  radius  =  15  ft 

if  ( (fabs(x_di f ference ) )  <=  ( f lowf ieldbox_length  *  FLOWFIELDLENGTH  )   && 

(fabs(y_dif ference) )  <=  ( f lowf ieldbox_width   *  FLOWFIELDWIDTH  +  15.0  )   && 
(fabs (z_dif ference) )  <=  ( f lowf ieldbox_height  *  40.0  ))  { 

//set  flag  to  perform  piecewise  calculations 
in_sub_f low_f ield  =  1 ; 

//calculate  difference  in  AUV  and  sub  course  +  speed 
AUV_SUB_Course_dif ference  =  submarine_course  -  AUV_heading; 

}  //end  of  if  in  flow  field 
}    //end  if  SUBMARINE_DOCKING 

//Loop  through  body  to  Initialize  all  Arrays,  perform  piecewise  calculations 

for  (int  x_index  =  0;  x_index  <=  cross_sections  -  1;  x_index++) 

{ 

pw_dx[x_index]  =  fabs (xx [x_index]  -  xx[x_index  +  1]  )  ; 

if  (x_index  ==0)  { 

pw_nose_length [x_index]  =  pw_dx [x_ index] /2 . 0 ; 
} 
else  { 

pw_nose_length[x_index]  =  pw_dx[x_ index] /2 . 0  +  pw_nose_length[x_index  -  1]  + 
pw_dx [ x_index  -  1 ] / 2 . 0 ; 
} 

//Calculate  pushup  -  the  amount  this  sections  pw_AUV_z  dif feres  from  the  overall 
AUV_Z 

pushup [x_index]  =  (xx[x_index]  +  pw_dx [x_index] /2 . 0)  *  sinTHETA; 

//Calculate  pw_AUV_z 

pw_AUV_z [x_index]  =  AUV_z  -  pushup [x_ index ] ; 

//Here  we  perform  all  calulations  for  piecewise  flow  field  forces 
//if  AUV  is  in  sub  torpedotube  area 
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sub 


if  (in_sub_flow_field  ==  TRUE)  { 

//Calculate  an  exact  x  &  y  for  each  section 

pw_AUV_x[x_ index]  =  AUV_x  +  (sin(90  -  AUV_SUB_Course_dif f erence)  * 

(xx[x_index]  +  pw_dx[x_index] /2 . 0 ) ) ; 

pw_AUV_y[x_ index]  =  AUV_y  +  (sin (AUV_SUB_Course_dif f erence)  * 

(xx[x_index]  +  pw_dx [x_index] /2 . 0) ) ; 

//Translate  the  x  and  y  into  grid  coordinates  based  on  position  relative  to  sub 
//this  takes  position  in  feet  and  gives  diff  in  ft 
grid_x_dif ference  =  ( (double) submarine_x  -   pw_AUV_x[x_index] ) ; 
grid_r_dif ference  =  sqrt  ( (pow( (double) submarine_y  -   pw_AUV_y[x_ index ] ,  2))  + 

(pow( (double) submarine_z  -   pw_AUV_z [x_index] ,  2))); 

//Assuming  each  integer  differnce  equals  one  foot,  this  translates  the  difference 
//between  sub  and  auv  (x,y)  into  a  coordinate  in  the  grids  reference.  The 
//grid  starts  with  (0,0)  at  the  bow  and  (720,  0)  at  the  stern.  The  center  ofthe 

//  is  actually  at  grid  position  (360,  0)  . 
if  (grid_x_dif ference  >=  0)  { 

pw_f lowf ield_x[x_index]  =  360  +  (int)(2  *  grid_x_dif ference) ; 
) 
else  { 

pw_f lowf ield_x[x_index]  =  360  +  (int)(2  *  grid_x_dif ference) ; 
} 

//Here  15  is  subtracted  to  account  for  submarine  radius  (15  ft  =  3  0  .5  ft 
segments) 

pw_f lowf ield_r [x_index]  =  (int) ( (grid_r_dif ference  -  15.0)  *  2.0); 

//Check  to  make  sure  pw_flowfield  x  and  y  are  valid 
if  ( (pw_flowfield_x[x_index]  >=   FLOWFIELDLENGTH  -  1)  || 
(pw_f lowf ield_x[x_index]  <   0))  { 

if  (TRACE)  { 

//print  error  message 

qq^^  <<  "  **•*•******•*****************•*•******•*******"  <<  endl 

<<  "pw_f lowf ield_x[x_index]  for  AUV  section  "  <<  x_index 

<<  "  was  calculated  as  "   <<  pw_f lowf ield_x [x_index]  <<  endl; 

cout  <<  "Submarine  X  =  "  <<  submarine_x   <<  "  ft    Submarine_y  =  " 
<<  submarine_y  <<  "  ft"  «endl 

<<  "pw_AUV_x    =  "  <<  pw_AUV_x[x_index]  <<  "  ft   pw_AUV_y  =  " 
<<  pw_AUV_y [x_index]  <<  "  ft" 
<<  endl; 
cout  <<  "Value  reset  to  360"  <<  endl; 
} 

//Reset  the  values  to  middle  of  grid 
pw_f lowf ield_x [x_index]  =  360; 
} 

if  (pw_flowfield_r[x_index]  >=   FLOWFIELDWIDTH  -  1)  { 

if  (TRACE)  { 

//print  error  message 

cout  <<  "*****************************************•****»  <<  endl 
<<  "pw_f lowf ield_r [x_index]  for  AUV  section  "  <<  x_index 
<<  "  was  calculated  as  "   <<  pw_f lowf ield_r [x_index]  <<  endl; 

cout  <<  "Submarine  X  =  "  <<  submarine_x   «  "  ft    Submarine_y  =  " 
<<  submarine  y   <<  "  ft"  <<endl 
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3)) 

offset 

*  knots 

*/ 


<<  "pw_AUV_x     =  "  <<  pw_AUV_x[x_ index]   <<  "  ft    pw_AUV_y  = 

<<  pw_AUV_y [x_index]  <<  "  ft" 

<<  endl ; 

cout  <<  "Value  reset  to  1  ft  from  hull"  <<  endl; 
} 

//This  case  is  reached  most  when  AUV  hits  hull  Therefore  to  keep  flow 

//force  consistent  I  reset  the  flow  field  index  to  1 ,  or  6"  from  hull 

//Reset  the  value  to  next  to  hull 

pw_f lowf ield_r [x_index]  =  60; 
} 
else  if  (pw_f lowf ield_r [x_index]  <   0)  { 

i  f  ( TRACE )  { 

//print  error  message 

cout  <<  "**********************************************"  <<  endl 

<<  "pw_f lowf ield_r [x_index]  for  AUV  section  "  <<  x_index 

<<  "  was  calculated  as  "   <<  pw_f  lowf  ield_r  [x_index]  <<  endl  ,- 

cout  <<  "Submarine  X  =  "  <<  submarine_x   <<  "  ft    Submarine  y  =    " 
«    submarine_y   <<  "  ft"  <<endl 

<<  "pw_AUV_x    =  "  <<  pw_AUV_x[x_index]   <<  "  ft   pw_AUV_y  = 
<<  pw_AUV_y [x_index]  <<  "  ft" 
<<  endl ; 
cout  <<  "Value  reset  to  1  ft  from  hull"  <<  endl; 
} 

//This  case  is  reached  when  AUV  hits  hull  Therefore  to  keep  flow 
//force  consistent  I  reset  the  flow  field  index  to  1,  or  6"  from  hull 
//Reset  the  value  to  next  to  hull 
pw_f lowf ield_r [x_index]  -    1; 
} 


//Determine  which  flow  grid  to  use  based  on  pw_AUV_z  and  selected  model 

if  ( ( (fabs (AUV_TTube_z_difference)  <=  torpedo tube_height)  &&  (  FLOW_FIELD_MODE  == 

||  (FLOW_FIELD_MODE  ==2))   { 

//the  direction  should  always  be  submarine_course  +  flow  field  direction 

//The  flow  magnitude  here  is  converted  to  ft/sec  by  multiplying  by 
/* 

ft/sec  =  knots  *  2000  yds/hr*  3  ft/yd   *  hr/60  min  *  min/60  sec   =  1.667 


//Now  decide  which  level  of  the  tube  flow  fields  to  use 
if  (AUV_TTube_z_dif ference  >  3.0)  { 

//The  AUV  is  in  the  above  tube  zone 

//Next  select  the  appropriate  speed  matrix 
switch  ((int)  submarine_speed)  { 
case  1 : 

f low_force_direction[x_index]  =  submarine_course  + 


abovetubelevellktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_force_magnitude [x_index] . setValue 

(abovetubelevellktgrid[pw_f lowf ield_x[x_index] ] 
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[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 
abovetubelevellktgrid[pw_f lowf ield_x [x_index] ] 
[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 
abovetubelevellktgrid[pw_f lowf ield_x [x_index] ] 
[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 
case  2 : 

f low_force_direction[x_index]  =  submarine_course  + 

abovetubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

( above tube level 2 ktgr id [pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

abovetubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

abovetubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 

case  3 : 

f low_force_direction[x_index]  =  submarine_course  + 

abovetubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(abovetubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

abovetubelevel3ktgrid[pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

abovetubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 

default: 

cerr  <<  "The  submarine  is  moving  to  fast  for  the  AUV  to  dock  with. 
<<  endl ; 

break ; 

} 

} 
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else  if  (AUV_TTube_z_dif ference  >  1.0)  { 
//THe  AUV  is  at  the  upper  tube  edge  zone 

//Next  select  the  appropriate  speed  matrix 
switch  ((int)  submarine_speed)  { 
case  1 : 

f low_f orce_direction [x_index]  =  submarine_course  + 

uppertubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(uppertubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

uppertubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

uppertubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break ; 

case  2 : 

f low_force_direction [x_index]  =  submarine_course  + 

uppertubelevel2ktgrid[pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(uppertubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

uppertubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

uppertubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break ; 

case  3  : 

f low_force_direction [x_index]  =  submarine_course  + 

uppertubelevel3ktgrid [pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(uppertubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

uppertubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 
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[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 
uppertubelevel3ktgrid[pw_f lowf ield_x [x_index] ] 
[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 


«  endl ; 


default: 

cerr  <<  "The  submarine  is  moving  to  fast  for  the  AUV  to  dock  with. 

break; 


else  if  (AUV_TTube_z_dif ference  >  -1.0)  { 

//The  AUV  is  in  the  center  of  the  tube  zone 


//Next  select  the  appropriate  speed  matrix 
switch  ((int)  submarine_speed)  { 
case  1 : 

f low_force_direction[x_index]  =  submarine_course  + 

centertubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(centertubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

centertubelevellktgrid [pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

centertubelevellktgrid [pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 

case  2 : 

f low_force_direction[x_index]  =  submarine_course  + 

centertubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(centertubelevel2ktgrid[pw_flowf ield_x[x_index] ] 

tpw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

centertubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

centertubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 


-100- 


break; 

case  3 : 

f low_f orce_direction[x_index]  =  submarine_course  + 

centertubelevel3ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(centertubelevel3ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . x_magnitude  *  1.667, 

centertubelevel3ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

centertubelevel3ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 


<<  endl ; 


default : 

cerr  <<  "The  submarine  is  moving  to  fast  for  the  AUV  to  dock  with. 

break; 


else  if  (AUV_TTube_z_dif ference  >  -3.0)  { 
//The  AUV  is  in  the  lower  tube  edge  zone 

//Next  select  the  appropriate  speed  matrix 
switch  ((int)  submarine_speed)  { 
case  1 : 

f low_force_direction[x_index]  =  submarine_course  + 

lowertubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

( lowertubelevellktgrid [pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

lowertubelevellktgrid [pw_f lowf ield_x[x_index] ] 

[pw_flowf ield_r [x_index] ] .y_magnitude  *  1.667, 

lowertubelevellktgrid [pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break ; 
case  2 : 

f low_force_direction[x_index]  =  submarine_course  + 
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lowertubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

( lowertubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

lowertubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

lowertubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 

case  3 : 

f low_force_direction[x_index]  =  submarine_course  + 

lowertubelevel3ktgrid[pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(lowertubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

lowertubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

lowertubelevel3ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 


«  endl ; 


default: 

cerr  <<  "The  submarine  is  moving  to  fast  for  the  AUV  to  dock  with. 

break; 


else  { 

//The  AUV  is  in  the  below  tube  zone 


//Next  select  the  appropriate  speed  matrix 
switch  ((int)  submarine_speed)  { 
case  1 : 

f low_force_direction[x_index]  =  submarine_course  + 

belowtubelevellktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 
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(belowtubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

belowtubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

belowtubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 

case  2 : 

f low_force_direction[x_index]  =  submarine_course  + 

belowtubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(belowtubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

belowtubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

belowtubelevel2ktgrid[pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break ; 
case  3 : 

f low_force_direction [x_index]  =  submarine_course  + 

belowtubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_force_magnitude [x_index] . setValue 

(belowtubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_flowfield_r [x_index] ] .x_magnitude  *  1.667, 
belowtubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 
belowtubelevel3ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break ; 

default: 

cerr  <<  "The  submarine  is  moving  to  fast  for  the  AUV  to  dock  with. 
<<  endl ; 

break; 
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} 

}  //End  of  If  that  decides  tube  level 

}    //End  of  if  which  decides  flat/tube  profile 

//This  is  the  case  of  being  in  a  flat  plate  field  region 
else   { 

//Next  select  the  appropriate  speed  matrix 
switch  ((int)  submarine_speed)  { 
case  1 : 

f  low_force_direction[x_index]  =  submarine_course  + 

nontubelevellktgrid [pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_force_magnitude [x_index] .setValue 

(nontubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

nontubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

nontubelevellktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 
case  2 : 

f low_force_direction[x_index]  =  submarine_course  + 

nontubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 

f low_f orce_magnitude [x_index] . setValue 

(nontubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 

nontubelevel2ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 

nontubelevel2ktgrid[pw_f lowf ield_x[x_index] ] 

[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break ; 

case  3 : 

f low_force_direction [x_index]  =  submarine_course  + 

nontubelevel3ktgrid [pw_f lowf ield_x [x_index] ] 

[pw_f lowf ield_r [x_index] ] .direction; 
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f low_f orce_magnitude [x_index] . setValue 
(nontubelevel3ktgrid [pw_f lowf ield_x [x_index] ] 
[pw_f lowf ield_r [x_index] ] .x_magnitude  *  1.667, 
nontubelevel3ktgrid [pw_f lowf ield_x [x_index] ] 
[pw_f lowf ield_r [x_index] ] .y_magnitude  *  1.667, 
nontubelevel3ktgrid[pw_f lowf ield_x [x_index] ] 
[pw_f lowf ield_r [x_index] ] . z_magnitude  *  1.667)  ; 

break; 

default : 

cerr  <<  "The  submarine  is  moving  to  fast  for  the  AUV  to  dock  with." 
<<  endl ; 

break; 

} 

}   //end  of  else  for   flat  plate  region 

}    //end  of  in  flow  field  calculations 

//Check  Bouyancy  adjustment 

if       (pw_AUV_z [x_index]  <=  H  /  2.0)  //  transition,  calculate  broach 

extent 
{ 

if    (pw_AUV_z [x_index]  >=  -(H  /  2.0))        //  broach  region,  reduce  buoyancy 
{ 

pw_revisedBouyancy [x_index]  =  (Buoyancy/cross_sections)  *  (pw_AUV_z [x_index] 
+  H/2.0) /H; 
} 

else 
{ 

pw_revisedBouyancy [x_index]  =0.0;       //  completely  out  of  the  water 
} 
} 

else 
{ 

pw_revisedBouyancy [x_index]  =  (Buoyancy/cross_sections) ;   //  >  H/2,  no  broach, 
normal  submerged 

} 

//Global  wave  force  effects  in  ft  per  second 
U_waves [x_index] .setValue  (  K_waves  * 

(SeaState[SEASTATE] . H_s  *  SeaState [SEASTATE] . f reql* 
(cos  (  SeaState [ SEASTATE] . f reql* AUV_time  + 

SeaState [ SEASTATE] .wavelength*pw_nose_length[x_index]  )))  //  + 

//SeaState [SEASTATE] .H_s  *  SeaState [SEASTATE] . freq2* 

//     (cos  (  SeaState [ SEASTATE] . freq2*AUV_time  + 

// 
SeaState [SEASTATE] .wavelength*pw_nose_length[x_index]  ))  + 

// SeaState [ SEASTATE ] .H_s  *  SeaState [SEASTATE] . freq3* 

//     (cos  (  SeaState [SEASTATE] . freq3*AUV_time   + 

// 
SeaState [SEASTATE] . wavelength*pw_nose_length[x_index]  ) ) ) 

*(cos  (heading_wave_l  -  AUV_psi)) 
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0.0, 

K_waves  * 
(SeaState[SEASTATE] .H_s  *  SeaState [SEASTATE] . f reql* 

(cos  (  SeaState [SEASTATE] .f reql* AUV_time  +  90.0  + 

SeaState [SEASTATE] . wavelength*pw_nose_length [x_index]  )))   //  + 

//SeaState [SEASTATE] .H_s  *  SeaState [SEASTATE] . freq2* 

//      (cos  (  SeaState [ SEASTATE] . freq2*AUV_time  +  90.0  + 

// 

SeaState [SEASTATE] .wavelength*pw_nose_length[x_index]  ))  + 

/ /SeaState [ SEASTATE] .H_s  *  SeaState [SEASTATE] . freq3* 

//      (cos  (  SeaState [ SEASTATE] . freq3*AUV_time  +  90.0  + 

// 

SeaState [SEASTATE] .wavelength*pw_nose_length[x_index] ) ) ) 

* (cos  (heading_wave_l  -  AUV_psi)) 

); 

//At  depth  >  20   we  reduce  the  wave  motion  effect  linearly,  deeper  than  100'  wave 
effect  is  negligible 

if  (AUV_z  >  20.0) 
{ 

U_waves[x_index] .setValue  (  U_waves [x_index] [1]  *  ( (100 . 0-AUV_z) /100 . 0) , 

0.0, 
U_waves[x_index] [3]  *  ( (100 . 0-AUV_z) /100 . 0)  )  ; 

}  else  if  (AUV_z  >  100)  { 

U_waves [x_index] .setValue  (  0.0,  0.0,  0.0); 

} 

//Check  for  revised_x_B  adjustment 

if       ( (THETA  ==0.0)  ||  (pw_AUV_z[x_index]  >=  H  /  2.0)) 

{ 

pw_revised_x_B[x_index]   =  xx[x_index]  +  (pw_dx [x_index] /2 . 0) ;  //  prevent 
divide-by-zero  case  and  too-deep  case 
} 

else  if  (THETA  >  0.0) 
{ 

pw_surface_length[x_index]    =   pw_AUV_z [x_index]    /    sinTHETA; 

} 

else  if  (THETA  <  0.0) 

{ 

pw_surface_length[x_index]  =  pw_AUV_z [x_index]  /  (-  sinTHETA); 

} 

else 

{ 

cout  <<  "Unexpected  case  in  revised  CB  calculation!"  <<  endl; 

pw_revised_x_B[x_index]   =  xx[x_index]  +  ( pw_dx [ x_index ] / 2 . 0 ) ;  //  prevent  divide 
by  zero  case 
) 

if  ((THETA  !=  0.0)  &&  (pw_surf ace_length [x_index]  <  pw_nose_length[x_index] )  && 
(pw_AUV_z[x_index]  <=  H  /  2.0)) 

//  move  x_CB  aft  (fwd)  but  only  if  nose  (stern)  broaches  the  surface 
{ 

pw_revised_x_B[x_index]   =  (xx[x_index]  +  (pw_dx [x_index] /2 . 0) )  - 
(pw_nose_length[x_index]  -  pw_surface_length[x_index] )  *  sinTHETA  /  2.0; 

//cout  <<  "pw_revised_x_B  in  case  one (nose  out)  =  "  <<  pw_revised_x_B[x_index] << 
endl ; 
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} 

else  { 

pw_revised_x_B [x_index]  =   (xx [x_index]  +  (pw_dx[x_index] /2  .  0)  )  ; 

//cout  <<  "pw_revised_x_B  in  case  2=  "  <<  pw_revised_x_B[x_ index] <<  endl, 

} 

if  (TRACE  | |  TRACE_EOM) 
{ 

cout  <<  "AUV_Z  =  "  <<  AUV_z    <<  endl; 

cout  <<  x_index  <<  "   pw_dx  =  "  <<  pw_dx [x_ index]  <<  endl; 

cout  <<  "xx  =  "  <<  xx[x_index]  <<  endl; 

cout  <<  "sinTHETA  =  "  <<  sinTHETA  <<  endl; 

cout  <<  "pushup  =  "  <<  pushup [x_index] <<  endl; 

cout  <<  "pw_AUV_z  =  "  <<  pw_AUV_z [x_index] <<  endl; 

cout  <<  "pw_nose_length  =  "  <<  pw_nose_length[x_index] <<  endl; 

cout  <<  "pw_surface_length  =  "  <<  pw_surface_length[x_index] <<  endl; 

cout  <<  "pw_revisedBouyancy  =  "  <<  pw_revisedBouyancy[x_index] <<  endl; 

cout  <<  "pw_revised_x_B  =  "  <<  pw_revised_x_B[x_index] <<  endl; 
} 

}  //end  for  loop 

//Loop  to  sum  up  piecewise  bouyancy  and  x_b  effects 
revisedBuoyancy  =  0.0; 
revised_x_B      =  0.0; 

for  (int  xl_index  =  0;  xl_index  <=  cross_sections  -  1;  xl_index++)   { 

revisedBuoyancy  =  revisedBuoyancy  +  pw_revisedBouyancy [xl_index] ; 

revised_x_B  =  revised_x_B  +  ( (xx[xl_index]  +  pw_dx[xl_index] /2 . 0)  - 
(pw_revised_x_B[xl_index] ) ) ; 

}   //end  for  loop 

revised_x_B  =  x_B  -  revised_x_B; 

if  (TRACE  | |  TRACE_EOM) 

{ 

cout  <<  "revisedBuoyancy  =  "  <<   revisedBuoyancy  <<  ",  "; 

cout  <<  "Weight  =  "          <<   Weight          <<  " ,  " ; 

cout  <<  endl; 

cout  <<  "  surface_length  =  "   <<  surface_length   <<  " ,  " 

cout  <<  "nose_length  =  "      <<   nose_length     <<  " ,  " 

cout  <<  "revised_x_B  =  "      <<   revised_x_B     <<  endl 

} 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

II    integrate  drag  forces  over  the  vehicle  -----------------// 

//  corresponding  to  cross-body  flow.   Use  cross-sectional  slices.  -  -  -  -  -// 

//This  section  of  code  creates  the  rotation  matrix  which  will  be  used  later  to 
//transform  flow  filed  components  from  the  sub's  reference  frame  to  the  AUV's 
f low_rotation_matrix. set_identity ( ) ; 
flow_rotation_matrix. rotate   (submarine_roll  -  AUV_phi , 

-107- 


submarine_pitch  -  AUV_theta, 
submarine_course  -  AUV_psi) ; 

//This  starts  the  summation  of  cross  body  drag  forces.  The  following  if  statement 
//allows  for  2  different  modes  of  cross  body  calculations,  one  for   a  circular  hull 
//and  one  for  a  square  hull.  The  type  of  Hull  is  required  to  be  defined  in  UUVmodel.H 

if  (SQUARE_HULL  ==  TRUE)  { 

//  traverse  longitudinal  centerline:   index  through  x  coordinate  arrays 
for  (int  x2_index  =  0;  x2_index  <=  cross_sections  -  1;  x2_index++)   { 

//Calculate  the  effects  of  sub  flow  field 
if  ( in_sub_f low_f ield  ==1)  { 

//here  flow  forces  are  due  to  flow  field  +  wave  motion 
f low_f orce_magnitude [x2_index]  =  f low_force_magnitude [x2_index]  + 
U_waves [x2_index] ; 

} 
else  { 

//here  flow  forces  are  due  to  wave  motion  only 

f low_force_magnitude [x2_index]  =   U_waves [x2_index] ; 


//This  gets  U,  V,  W  from  (x-dot,  y-dot,  z-dot) *rotation  matrix  transpose 
pw_UVW. setValue (  f low_rotation_matrix  *  f low_force_magnitude [x2_index] ) ; 


if  (x2_index  ==1)  { 

temp_doppler_stw_u  =  pw_UVW[l]; 
temp_doppler_stw_v  =  pw_UVW[2]; 

} 


// 

//  these  integrals  are  for  wave  and  flowinduced  drag  forces 

f low_f ield_sway_integral   +=    rho2  *  (  C_dy  *  hh  [x2_index] 

*  pw_UVW[2]  *  fabs(pw_UVW[2] ) ) 

*  pw_dx[x2_index] ; 

f low_f ield_surge_integral  =  0.0; 

f low_f ield_heave_integral  +=    rho2  *  (  C_dz  *  bb  [x2_index] 

*  pw_UVW[3]     *    fabs(pw_UVW[3] ) ) 

*  pw_dx[x2_index] ; 

f low_f ield_roll_integral  =   0.0; 

f low_f ield_pitch_integral  +=    rho2  *  (  C_dz  *  bb  [x2_index] 

*  pw_UVW[3]  *  fabs(pw_UVW[3] ) ) 
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*  xx  [x2_index]  *  pw_dx [x2_index; 


f low_f ield_yaw_integral    +=    rho2  *  (  C_dy  *  hh  [x2_index] 

*  pw_UVW[2]  *  fabs(pw_UVW[2] ) ) 

*  xx  [x2_index]  *  pw_dx[x2_index] 


// 

//  these  integrals  are  for  rigidbody  velocity  drag  forces 

sway_integral   +=    rho2  *  (  C_dy  *  hh  [x2_index] 

*  square  ( (V  +  xx  [x2_index]  *  R   ) )  ) 

*  pw_dx [x2_index] ; 
heave_integral  +=    rho2  *  (  C_dz  *  bb  [x2_index] 

*  square  ( (W  -  xx  [x2_index]  *  Q) ) ) 

*  pw_dx [x2_index] ; 
pitch_integral  +=    rho2  *  (  C_dz  *  bb  [x2_index] 

*  square  ( (W  -  xx  [x2_index]  *  Q) ) ) 

*  xx  [x2_index]  *  pw_dx [x2_index] ; 


yaw_integral    +=    rho2  *  (  C_dy  *  hh  [x2_index] 

*  square  ( (V   +  xx  [x2_index]  *  R  ) )  ) 

*  xx  [x2_index]  *  pw_dx[x2_index] ; 

roll_integral   +=   0.0; 


if  (TRACE  | |  TRACE_EOM) 


{ 


cout  <<  "dx  =  "  <<  pw_dx [x2_index]  <<  ",  U_cf_x  =  "  <<  U_cf_x 
<<  ",  sway_integral   =  "  <<  sway_integral  <<  endl; 

cout  <<  "dx  =  "  <<  pw_dx[x2_index]  <<  ",  U_cf_x  =  "  <<  U_cf_x 
<<  ",  heave_integral  =  "  <<  heave_integral  <<  endl; 

cout  <<  "dx  =  "  <<  pw_dx[x2_index]  <<  ",  U_cf_x  =  "  <<  U_cf_x 
<<  ",  pitch_integral  =  "  <<  pitch_integral  <<  endl; 


} 


cout  <<  "dx  =  "  <<  pw_dx [x2_ index]  <<  ",  U_cf_x  = 
<<  ",  yaw_integral    =  "  <<  yaw_integral  <<  endl; 


<<  U  cf  x 


}  //end  for  loop 
}  //End  of  the  square  hull  case 
//This  starts  the  round  hull  case  of  cross  body  drag 
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else  { 


//  traverse  longitudinal  centerline:   index  through  x  coordinate  arrays 
for  (int  x2_index  =  0;  x2_index  <=  cross_sections  -  1;  x2_index++)   { 
U_cf_x  =  sqrt  (   square  (V  +  xx  [x2_index]  *  R) 

+  square  (W  -  xx  [x2_index]  *  Q) ) ; 

if  (U_cf_x  >  1.0E-6)  //  arbitrary  small  non-0  minimum 
{ 


//Calculate  the  effects  of  sub  flow  field 
if  (in_sub_f low_f ield  ==1)  { 

//here  flow  forces  are  due  to  flow  field  +  wave  motion 
f low_force_magnitude [x2_index]  =  f low_force_magnitude[x2_index]  + 
U_waves [x2_index] ; 

} 
else  { 

//here  flow  forces  are  due  to  wave  motion  only 

f low_force_magnitude [x2_index]  =   U_waves [x2_index] ; 


//This  gets  U,  V,  W  from  (x-dot,  y-dot,  z-dot) *rotation  matrix  transpose 
pw_UVW. setValue (  f low_rotation_matrix  *  f low_force_magnitude [x2_index] ) ; 


if  (x2_index  ==1)  { 

temp_doppler_stw_u  =  pw_UVW[l] ; 

temp_doppler_stw_v  =  pw_UVW[2]; 
} 


// 

//  these  integrals  are  for  wave  and  flowinduced  drag  forces 

f low_f ield_sway_integral   +=   rho2  *  (  C_dy  *  hh  [x2_index] 

*  pw_UVW[2]  *  fabs(pw_UVW[2] ) ) 

*  pw_dx[x2_index] ; 

f low_f ield_surge_integral  =  0.0; 

f low_f ield_heave_integral  +=    rho2  *  (  C_dz  *  bb  [x2_index] 

*  pw_UVW[3]     *    fabs(pw_UVW[3] ) ) 

*  pw_dx[x2_index] ; 

f low_f ield_roll_integral  =   0.0; 

f low_field_pitch_integral  +=    rho2  *  (  C_dz  *  bb  [x2_index] 


-110- 


*  pw_UVW[3]  *  fabs(pw_UVW[3] ) ) 

*  xx  [x2_index]  *  pw_dx[x2_index] 


f low_f ield_yaw_integral 


U_c  f _x ; 


rho2  *  (  C_dy  *  hh  [x2_index] 

*  pw_UVW[2]  *  fabs(pw_UVW[2] ) ) 

*  xx  [x2_index]  *  pw_dx[x2_index] 


U_cf_x; 


// 

//  these  integrals  are  for  rigidbody  velocity  drag  forces 

sway_integral   +  =    rho2  *  (  C_dy  *  hh  [x2_index] 

*  square  ( (V  +  xx  [x2_index]  *  R   ) )  ) 

*  (V  +  xx  [x2_index]  *  R)  *  pw_dx [x2_index]  / 

heave_integral  +=    rho2  *  (  C_dz  *  bb  [x2_index] 

*  square  ( (W  -  xx  [x2_index]  *  Q) ) ) 

*  (W  -  xx  [x2_index]  *  Q)  *  pw_dx[x2_index]  / 


pitch_integral  += 


yaw_integral 


rho2  *  (  C_dz  *  bb  [x2_index] 

*  square  ( (W  -  xx  [x2_index]  *  Q) ) ) 

*  (W  -  xx  [x2_index]  *  Q) 

*  xx  [x2_index]  *  pw_dx [x2_index]  /  U_cf_x; 

rho2  *  (  C_dy  *  hh  [x2_index] 

*  square  ( (V  +  xx  [x2_index]  *  R  ) )  ) 

*  (V  +  xx  [x2_index]  *  R) 

*  xx  [x2_index]  *  pw_dx [x2_index]  /  U_cf_x; 


//end  of  if  (U_cf_x  >  1.0E-6) 


i  f  ( TRACE 
{ 


TRACE_EOM) 


cout  <<  "dx  =  "  <<  pw_dx[x2_index]  <<  ",  U_cf_x  =  "  <<  U_cf_x 
<<  ",  sway_integral   =  "  <<  sway_integral  <<  endl; 

cout  <<  "dx  =  "  <<  pw_dx [x2_index]  <<  ",  U_cf_x  =  "  <<  U_cf_x 
<<  ",  heave_integral  =  "  <<  heave_integral  <<  endl; 

cout  <<  "dx  =  "  <<  pw_dx[x2_index]  <<  ",  U_cf_x  =  "  <<  U_cf_x 
<<  ",  pitch_integral  =  "  <<  pitch_integral  <<  endl; 


cout  <<  "dx  =  "  <<  pw_dx[x2_index]  <<  ",  U_cf_x  = 
<<  ",  yaw_integral    =  "  <<  yaw_integral  <<  endl; 


<<  U  cf  x 
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}  //end  for  loop 

}   //End  of  the  round  hull  case  of  cross  body  drag 

//Add  effects  of  flow  field  integral's  to  eom  integrals 

sway_integral  +-  f low_f ield_sway_integral; 

heave_integral  +=  f low_f ield_heave_integral; 

pitch_integral  +=  f  low_f  ield_pitch_integral  ; 

yaw_integral  +=  f low_f ield_yaw_integral; 

roll_integral  +=  f low_f ield_roll_integral; 

surge_integral  +=  f low_f ield_surge_integral;  //  unused 

//set  doppler  velocities  for  speed  through  water  in  ft/sec 
doppler_stw_u  =   temp_doppler_stw_u; 
doppler_stw_v  -      temp_doppler_stw_v; 

}   //end  new  bouyancy  model 

1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 II 1 1  HI  III  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

II    debug  section.   selectively  set  sway/heave/pitch/yaw  integrals  to  zero  to 
//  isolate  problems.   also  see  zeroing  of  rhs  values. 

//  sway_integral  =  0.0; 

//  heave_integral  =  0.0; 

//  pitch_integral  =  0.0; 
//    yaw_integral  =  0.0; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

II    reduce  efficiency  if  propellers  operating  astern  -----------  -// 

double  port_propeller_ef f iciency,  stbd_propeller_eff iciency; 

if  (AUV_port_rpm  >=  0.0)  port_propeller_eff iciency  =  1.0; 

else  port_propeller_eff iciency  =  X_astern_eff iciency; 

if  (AUV_stbd_rpm  >=  0.0)  stbd_propeller_eff iciency  =  1.0; 

else  stbd_propeller_eff iciency  =  X_astern_eff iciency; 

/ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
II    calculate  Equations  of  Motion  right-hand  sides  // 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

rhs  [SURGE]  =  //  Surge  Motion  Equation  right  hand  side // 

m  *  (  (V  *  R)  -  (W  *  Q)  +  x_G  *  (Q2  +  R2 )  -  y_G  *  P*Q  -  z_G  *  P*R) 

+  rho2  *  L4  *  (   X_pp  *  P2   +  X_qq  *  Q2 

+  X_rr  *  R2   +  X_pr  *  P*R) 

+  rho2  *  L3  *  (   X_wq  *  W*Q  +  X_vp  *  V*P  +  X_vr  *  V*R 

+  U*Q  *  (   X_uq_delta_bow     *  delta_planes_bow 

+  X_uq_delta_stern    *  delta_planes_stern) 

+  U*R  *  (   X_ur_delta_rudder   *  delta_rudder_bow 

+  X_ur_delta_rudder   *  delta_rudder_stern) 
) 

+  rho2  *  L2  *  (   X_w  *  V2   +  X_ww  *  W2 

+  U*V  *  (   X_uv_delta_rudder   *  delta_rudder_stern) 

+  U*W  *  (   X_uw_delta_bow     *  delta_planes_bow 
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+  X_uw_delta_stern    *  delta_planes_stern) 

+  U  *  fabs  (U)   *  (   X_uu_delta_b_delta_b 

*  delta_planes_bow 

*  delta_planes_bow 

+  X_uu_delta_s_delta_s 

*  delta_planes_stern 

*  delta_planes_stern 

+  X_uu_delta_r_delta_r 

*  delta_rudder_bow 

*  de 1 1  a_rudder_bow 

+  X_uu_delta_r_delta_r 

*  delta_rudder_stern 

*  delta_rudder_stern) 
) 

-  (Weight  -  revisedBuoyancy)  *  sinTHETA 

//  EPSILON  terms  have  been  removed  due  to  revised  equations  of  motion 

//  +  rho2  *  L3  *    X_qdsn   *  U*Q  *  del ta_planes_s tern  *  EPSILON 

//  +  rho2  *  L2  *  EPSILON  *  (  X_wdsn   *  U*W  *  delta_planes_stern 

// 

//  +  X_dsdsn  *  U2        *  delta_planes_stern 

//  *  delta_planes_stern) 

//  X_propulsion  surge  force  (derived  using  expressions  in  Healey  paper) 
//  note  that  SPEED_PER_RPM  is  associated  with  work  of  two  propellors 

+  rho2  *  L2  *  C_dO  *   square  (SPEED_PER_RPM) 

*   0.5  *  (   AUV_port_rpm  *  fabs  (AUV_port_rpm) 

*  port_propeller_ef f iciency 

+  AUV_stbd_rpm  *  fabs  (AUV_stbd_rpm) 

*  stbd_propeller_eff iciency) 

//  X_resistance  surge  drag  (derived  using  expressions  in  Healey  paper) 

-  rho2  *  L2  *  C_d0  *  U  *  fabs  (U) ; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

if  (TRACE  ||  TRACE_EOM  ||  (rhs  [SURGE]  >=  MAX_SURGE) )    //  Surge  TRACE 

{ 

cout  <<  "*  surge  terml="  <<   m  *  ( (V  *  R)  -  (W  *  Q) 

+  x_G  *  (Q2  +  R2)  -  y_G  *  P*Q  -  z_G  *  P*R)«  endl; 

cout  «  "term2="  <<    +  rho2  *  L4  *  (   X_pp  *  P2   +  X_qq  *  Q2 

+  X_rr  *  R2   +  X_pr  *  P*R) 
<<  endl; 

cout  <<  "term3="  <<    +  rho2  *  L3  *  (   X_wq  *  W*Q  +  X_vp  *  V*P  +  X_vr  *  V*R 

+  U*Q  *  (   X_uq_delta_bow      *  delta_planes_bow 

+  X_uq_delta_stern    *  delta_planes_stern) 

+  U*R  *  (   X_ur_delta_rudder   *  delta_rudder_stern 
+  X_ur_delta_rudder   *  delta_rudder_bow) 

) 
<<  endl ; 
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cout  «  "term4="  «    +  rho2  *  L2  *  (   X_w  *  V2   +  X_ww  *  W2 

+  U*V  *  (   X_uv_delta_rudder   *  del ta_rudder_s tern) 

+  U*W  *  (   X_uw_delta_bow     *  delta_planes_bow 

+  X_uw_delta_stern    *  delta_planes_stern) 

+  U  *  fabs  (U)   *  (   X_uu_delta_b_delta_b 

*  delta_planes_bow 

*  delta_planes_bow 

+  X_uu_delta_s_delta_s 

*  delta_planes_stern 

*  delta_planes_stern 

+  X_uu_delta_r_delta_r 

*  delta_rudder_bow 

*  delta_rudder_bow 

+  X_uu_delta_r_delta_r 

*  delta_rudder_stern 

*  delta_rudder_stern) 
) 

<<  endl ; 

cout  <<  "term5="  <<  -  (Weight  -  revisedBuoyancy)  *  sinTHETA 
<<  endl ; 

cout  <<  " term6, term7="  <<    "EPSILON  terms,  no  longer  used" 
<<  endl ; 

//  cout  «  "term6="  <<   rho2  *  L3  *    X_qdsn   *  U*Q  *  delta_planes_stern 

//       *  EPSILON  <<  endl; 

// 

//  cout  «  "term7="  <<   rho2  *  L2  *  EPSILON  *  (  X_wdsn   *  U*W 

//  *  delta_planes_stern 

//  +  X_dsdsn  *  U2         *  delta_planes_stern 

//  *  delta_planes_stern) 

/ /       <<  endl ; 

cout  «  "term8="  <<   +  rho2  *  L2  *  C_dO  *   square  (SPEED_PER_RPM) 

*   0 . 5  *  (   AUV_port_rpm  *  fabs  (AUV_port_rpm) 

*  port_propeller_ef f iciency 

+  AUV_stbd_rpm  *  fabs  (AUV_stbd_rpm) 

*  stbd_propeller_eff iciency) 
<<  endl ; 

cout  <<  "term9="  <<  -  rho2  *  L2  *  C_dO  *  U  *  fabs  (U) 

<<  endl ; 
} 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

rhs  [SWAY  ]  =  //  Sway  Motion  Equation  right  hand  side // 

m  *  (-  (U  *  R)  +  (W  *  P)  -  x_G  *  (P  *  Q) 

+  y_G  *  (P2  +  R2) 

-  z_G  *  (Q   *  R)  ) 

+  rho2  *  L4  *  (   Y_pq     *  P*Q     +  Y_qr    *  Q*R) 
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+  rho2  *  L3  *  (   Y_up     *  U*P    +  Y_ur  *  U*R 

+  Y_vq     *  V*Q     +  Y_wp  *  W*P     +   Y_wr  *  W*R) 

+  rho2  *  L2  *  (   Y_uv     *  U*V     +  Y_vw  *  V*W 

+  U*fabs(U)  *  Y_uu_delta_rb  *  delta_rudder_bow 

+  U*fabs(U)  *  Y_uu_delta_rs  *  delta_rudder_stern) 

-  sway_integral 

+  (Weight  -  revisedBuoyancy)  *  cosTHETA  *  sinPHI 

(2 .0  /  (24. 0  *  24.0) )   //  each  thruster  2 . 0  lb  per  24V  signal  squared 

*  (   AUV_bow_lateral    *  fabs  (AUV_bow_lateral) 

+  AUV_stern_lateral  *  fabs  (AUV_stern_lateral) ) ; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  / 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

if  (TRACE  ||  TRACE_EOM  ||   (rhs  [SWAY]  >=  MAX_SWAY) )     //  Sway  TRACE 

{ 

cout  <<  "*  sway  terml="  <<   m  *  ( -  (U  *  R)  +  (W  *  P) 

-  x_G  *  (P  *  Q) 

+  y_G  *  (P2  +  R2) 

-  z_G  *  (Q   *  R)  ) 


<<  endl; 

cout  «  "term2="  << 

<<  endl; 

cout  <<  "term3="  << 


<<  endl ; 

cout  <<  "term4="  << 

<<  endl ; 

cout  <<  "term5="  << 

<<  endl ; 

cout  <<  "term6="  << 

<<  endl ; 

cout  <<  "term7="  << 


+  rho2  *  L4  *  (   Y_pq 


P*Q 


+  Y_qr    *  Q*R) 


} 


<<  endl ; 


+  rho2  *  L3  *  (   Y_up     *  U*P     +   Y_ur   *  U*R 
+  Y_vq     *  V*Q     +  Y_wp    *  W*P     +   Y_wr  *  W*R) 

+  rho2  *  L2  *  (   Y_uv      *  U*V     +  Y_vw    *  V*W 
+  U*fabs(U)  *  Y_uu_delta_rb  *  delta_rudder_bow 
+  U*fabs(U)  *  Y_uu_delta_rs  *  delta_rudder_stern) 

-  sway_integral  <<  "  sway_integral" 

+  (Weight  -  revisedBuoyancy)  *  cosTHETA  *  sinPHI 


-   (2.0  /  (24.0  *  24.0) ) 
//  each  thruster  2.0  lb  per  24V  signal  squared 

AUV_bow_lateral    *  fabs  (AUV_bow_lateral) 
+  AUV_stern_lateral  *  fabs  (AUV_stern_lateral) ) 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
rhs  [HEAVE]  =  //  Heave  Motion  Equation  right  hand  side // 
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m  *  (   (U  *  Q)  -  (V  *  P)  -  x_G  *  (P  *  R)  -  y_G  *  (Q  *  R) 

+  z_G  *  (P2  +  Q2) ) 

+  rho2  *  L4  *  (   Z_pp     *  P2      +  Z_pr  *  P*R     +  Z_rr  *  R2 ) 

+  rho2  *  L3  *  (   Z_uq     *  U*Q     +  Z_vp  *  V*P     +  Z_vr  *  V*R) 

+  rho2  *  L2  *  (   Z_uw     *  U*W    +  Z_w  *  V2 

+  (  U*fabs(U)  *  Z_uu_delta_b  *  delta_planes_bow   ) 
+  (  U*fabs(U)  *  Z_uu_delta_s  *  delta_planes_stern) ) 

-  heave_integral 

+  (Weight  -  revisedBuoyancy)  *  cosTHETA  *  cosPHI 

//  EPSILON  terms  have  been  removed  due  to  revised  equations  of  motion 

//  +  rho2  *  L3  *     Z_qn   *  U*Q  *  EPSILON 

//  +  rho2  *  L2  *  (   Z_wn   *  U*W 

//  +  Z_dsn  *  U*fabs(U)  *  delta_planes_stern)  *  EPSILON 

+   (2.0  /  (24.0  *  24.0))   //  each  thruster  2.0  lb  per  24V  signal  squared 

*  (  AUV_bow_vertical    *  fabs  (AUV_bow_vertical)   + 
AUV_stern_vertical  *  fabs  (AUV_stern_vertical) ) ; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

if  (TRACE  ||  TRACE_EOM  ||  (rhs  [HEAVE]  >=  MAX_HEAVE) )    //  Heave  TRACE 
{ 

cout  «  "*  heave  terml="  «   m  *  (   (U  *  Q)  -  (V  *  P)  -  x_G  *  (P  *  R) 

-  y_G  *  (Q  *  R) 


+  z_G  *  (P2  +  Q2)  ) 


«  endl ; 


cout  «  "term2="  <<    +  rho2  *  L4  *  (   Z_pp     *  P2      +  Z_pr     *  P*R 
+  Z_rr  *  R2)  «  endl; 

cout  «  "term3="  «    +  rho2  *  L3  *  (   Z_uq     *  U*Q    +  Z_vp  *  V*P 
+  Z_vr  *  V*R)  «  endl; 

cout  «  "term4="  «    +  rho2  *  L2  *  (   Z_uw     *  U*W    +  Z_w   *  V2 

+  (  U*fabs(U)  *  Z_uu_delta_b  *  delta_planes_bow   ) 

+  (  U*fabs(U)  *  Z_uu_delta_s  *  delta_planes_stern) ) 
<<  endl ; 

cout  <<  "term5="  <<    -  heave_integral  <<  "  heave_integral" 
<<  endl ; 

cout  <<  "term6="  <<    +  (Weight  -  revisedBuoyancy)  *  cosTHETA  *  cosPHI 
<<  endl; 

cout  <<  "term7,  term8="  <<    "no  longer  used" 
<<  endl ; 

cout  <<  "term9="  <<    +   (2.0  /  (24.0  *  24.0)) 

//  each  thruster  2.0  lb  per  24V  signal  squared 

*  (  AUV_bow_vertical    *  fabs  (AUV_bow_vertical)   + 
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AUV_stern_vertical  *  fabs  (AUV_stern_vertical )  ) 
<<  endl; 

} 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
rhs  [ROLL  ]  =  //  Roll   Motion  Equation  right  hand  side // 

-  (I_z  -  I_y)  *  Q*R  -  I_xy  *  P*R  +  I_yz  *  (Q2  -  R2)  +  I_xz  *  P*Q 

-  m  *  (  y_G  *  (  -U*Q  +  V*P)  -  z_G   *  (  U*R  -  W*P) ) 

+  rho2  *  L5   *  (   K_pq  *  P*Q   +  K_qr  *  Q*R 

+  K_pp  *  P  *  fabs(P) 

+  K_p   *  P  )  1 1    hovering  roll  drag 

+  rho2  *  L4   *  (  K_up  *  fabs(U)*P   +  K_ur  *  U*R   +  K_vq  *  V*Q 

+  K_wp  *  W*P   +  K_wr  *  W*R) 

+  rho2  *  L3   *  (   K_uv  *  U*V   +  K_vw  *  V*W 

-  U*fabs(U)  *  0.5  *  (   K_uu_planes  *  delta_planes_bow 

+  K_uu_planes  *  delta_planes_stern) 

-  U*fabs(U)  *  0.5  *  (   K_uu_rudder  *  delta_rudder_bow 

+  K_uu_rudder  *  del ta_rudder_s tern) ) 

//Added  roll  integral  for  square  hull  model 
+  roll_integral 

//  expected:  opposed  plane  directions  A  cause  negation  &  cancellation 

+  (y_G  *  Weight  -  y_B  *  revisedBuoyancy)  *  cosTHETA  *  cosPHI 

-  (z_G  *  Weight  -  z_B  *  revisedBuoyancy)  *  cosTHETA  *  sinPHI; 

//  EPSILON  terms  have  been  removed  due  to  revised  equations  of  motion 
//  +  rho2  *  L4  *  K_pn  *  U*P  *  EPSILON 

//  +  rho2  *  L3  *  U*fabs(U)   *  K_prop;  //  oversimplified,  in  error 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

if  (TRACE  ||  TRACE_EOM  ||   (rhs  [ROLL]  >=  MAX_ROLL))     //  Roll  TRACE 
{ 

cout  <<  " *  roll  terml="  <<  -  (I_z  -  I_y)  *  Q*R  -  I_xy  *  P*R  +  I_yz  *  (Q2  -  R2) 

+  I_xz  *  P*Q 
<<  endl ; 

cout  «  "term2="  «  -  m  *  (  y_G  *  (  -U*Q  +  V*P)  -  z_G   *  (  U*R  -  W*P) ) 
<<  endl ; 

cout  <<  "term3="  <<  +  rho2  *  L5   *  (   K_pq  *  P*Q   +  K_qr  *  Q*R 

+  K_pp  *  p  *  fabs(P) 

+  K_p   *  P  )   //  hovering  roll  drag 

<<  endl; 

cout  <<  "term4="  «  +  rho2  *  L4   *  (  K_up   *  fabs(U)*P   +  K_ur  *  U*R 

+  K_vq  *  V*Q  +  K_wp  *  W*P   +  K_wr  *  W*R) 
<<  endl; 
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cout  <<  "term5="  «  +  rho2  *  L3   *  (   K_uv  *  U*V   +  K_vw  *  V*W 

-  U*fabs(U)  *  0.5  *  (   K_uu_planes  *  delta_planes_bow 

+  K_uu_planes  *  delta_planes_stern) 

-  U*fabs(U)  *  0.5  *  (   K_uu_rudder  *  delta_rudder_bow 

+  K_uu_rudder  *  del ta_rudder_s tern) ) 
//  expected:  opposed  plane  directions  A  cause  negation  &  cancellation 
<<  endl; 

cout  <<  "term6="  <<  +  (y_G  *  Weight  -  y_B  *  revisedBuoyancy)  *  cosTHETA  *  cosPHI 
<<  endl ; 

cout  <<  "term7="  <<  -  (z_G  *  Weight  -  z_B  *  revisedBuoyancy)  *  cosTHETA  *  sinPHI 
<<  endl; 

cout  <<  " term8, term9="  <<    "EPSILON  terms,  no  longer  used" 
<<  endl; 

//  cout  <<  "term8="  <<  +  rho2  *  L4  *  K_pn  *  U*P  *  EPSILON 
//       <<  endl; 

//  cout  <<  "term9="  <<  +  rho2  *  L3  *  U*fabs(U)   *  K_prop 

//      <<  endl; 

} 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

rhs  [PITCH]  =  //  Pitch  Motion  Equation  right  hand  side // 

-  (I_x  -  I_z)  *  P*R  +  I_xy  *  Q*R  -  I_yz  *  P*Q  -  I_xz  *  (P2  -  R2) 
+   m  *  (  x_G  *  (  -U*Q  +  V*P)  -  z_G   *  (  -  V*R  +  W*Q) ) 

+  rho2  *  L5   *  (   M_pp  *  P2    +  M_pr  *  P*R   +  M_rr  *  R*fabs  (R) 

+  M_q   *  Q 

+  M_qq  *  Q  *  fabs (Q) )   //  hovering  pitch  drag 

+  rho2  *  L4   *  (  M_uq  *  U*Q   +  M_vp  *  V*P   +  M_vr  *  V*R) 

+  rho2  *  L3   *  (  M_uw  *  U*W   +  M_w  *  V2 

+  U*fabs(U)  *  (   M_uu_delta_bow   *  delta_planes_bow 

+  M_uu_delta_stern  *  delta_planes_stern) ) 

+  pitch_integral   //  note  sign  corrections  to  Healey  pitch_integral 

-  (x_G  *  Weight    -   revised_x_B  *  revisedBuoyancy)  *  cosTHETA  *  cosPHI 

-  (z_G  *  Weight    -   z_B  *  revisedBuoyancy)  *  sinTHETA 

+   (2.0/  (24.0*  24.0))   //  each  thruster  2 . 0  lb  per  24V  signal  squared 

//  multiplied  by  respective  moment  arms 
//  x_bow_vertical  (+) ,  x_stern_vert  (-) 

*  (  (AUV_bow_vertical    *  fabs  (AUV_bow_vertical)    *  x_bow_vertical) 

+  (AUV_stern_vertical  *  fabs  (AUV_stern_vertical)  *  x_stern_vertical) )  , 

//  EPSILON  terms  have  been  removed  due  to  revised  equations  of  motion 
//  +  rho2  *  L4   *   M_qn  *  U*Q  *  EPSILON 

//  +  rho2  *  L3   *  (M_wn  *  U*W  +  M_dsn  *  U*fabs(U)  *  del ta_planes_s tern) 
//  *  EPSILON; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

-118- 


if  (TRACE  ||  TRACE_EOM  ||   (rhs  [PITCH]  >=  MAX_PITCH))     //  Pitch  TRACE 
{ 

cout  <<  "*  pitch  terml="  <<  -  ( I_x  -  I_z )  *  P*R  +  I_xy  *  Q*R  -  I_yz  *  P*Q 
-  I_xz  *  (P2  -  R2)  «  endl; 

cout  <<  "term2="  «  +   m  *  (  x_G  *  (  -U*Q  +  V*P)  -  z_G   *  (  -  V*R  +  W*Q) ) 
<<  endl; 

cout  <<  "term3="  <<  +  rho2  *  L5   *  (   M_pp  *  P2    +  M_pr  *  P*R   +  M_rr 

*  R*fabs  (R) 
+  M_q   *  Q 

+  M_qq  *  Q  *  fabs (Q) )   //  hovering  pitch  drag 
<<  endl ; 

cout  <<  "term4="  <<  +  rho2  *  L4   *  (  M_uq  *  U*Q   +  M_vp  *  V*P   +  M_vr  *  V*R) 
<<  endl; 

cout  «  "  term5="  <<  +  rho2  *  L3   *  (  M_uw  *  U*W   +  M_w  *  V2 

+  U*fabs(U)  *  (   M_uu_delta_bow    *  delta_planes_bow 

+  M_uu_delta_stern  *  delta_planes_stern) ) 
<<  endl ; 

cout  <<  "term6="  <<  +  pitch_integral  <<  "  pitch_integral" 
<<  endl; 

cout  <<  "term7="  <<  -  (x_G  *  Weight    -   revised_x_B  *  revisedBuoyancy) 

*  cosTHETA  *  cosPHI 
<<  endl; 

cout  <<  "term8="  <<  -  (z_G  *  Weight    -   z_B  *  revisedBuoyancy)  *  sinTHETA 
<<  endl; 

cout  «  "term9="  <<  +   (2.0  /  (24.0  *  24.0)) 

//  each  thruster  2.0  lb  per  24V  signal  squared 
//  multiplied  by  respective  moment  arms 
//  x_bow_vertical  (+) ,  x_stern_vert  (-) 

*  (  (AUV_bow_vertical    *  fabs  (AUV_bow_vertical)    *  x_bow_vertical) 
+ (AUV_stern_vertical  *  fabs  (AUV_stern_vertical)  *  x_stern_vertical) ) 
<<  endl; 

cout  <<  " termlO, termll="  <<    "EPSILON  terms,  no  longer  used" 
<<  endl; 

//  cout  <<  "terml0="  <<  +  rho2  *  L4   *   M_qn  *  U*Q  *  EPSILON 
//       <<  endl; 

//  cout  <<  "termll="  <<  +  rho2  *  L3   *  (M_wn  *  U*W  +  M_dsn  *  U*fabs(U) 

//  *  delta_planes_stern) 

//  *  EPSILON 

//      <<  endl; 

} 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
rhs  [YAW   ]  =  //  Yaw   Motion  Equation  right  hand  side // 

-  (I_y  -  I_x)  *  P*Q  +  I_xy  *  (P2  -  Q2 )  +  I_yz  *  P*R  -  I_xz  *  Q*R 

-  m  *  (  x_G  *  (  U*R  -  W*P)  -  y_G    *  (  -  V*R  +  W*Q) ) 
+  rho2  *  L5   *  (   N_pq  *  P*Q   +  N_qr  *  Q*R 

+  N_r   *  R 
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+  N_rr  *  R  *  fabs  (R) )   //  hovering  yaw  drag 

+  rho2  *  L4   *  (  N_up  *  U*P  +  N_ur  *  U*R   +  N_vq  *  V*Q 

+  N_wp  *  W*P  +  N_wr  *  W*R) 

+  rho2  *  L3   *  (  N_uv  *  U*V  +  N_vw  *  V*W 

+  U*fabs(U)  *  N_uu_delta_rb  *  delta_rudder_bow 

-  U*fabs(U)  *  N_uu_delta_rs  *  delta_rudder_stern) 

-  yaw_integral 

+  (x_G  *  Weight   -   revised_x_B  *  revisedBuoyancy)  *  cosTHETA  *  sinPHI 

+  (y_G  *  Weight   -   y_B  *  revisedBuoyancy)  *  sinTHETA 

(2.0  /  (24.0  *  24.0))  //  each  thruster  2 . 0  lb  per  24V  signal  squared 

//  multiplied  by  respective  moment  arms 

*  (  (AUV_bow_lat;eral    *  fabs  (AUV_bow_lateral)  *  x_bow_lateral    ) 

+ (AUV_stern_lateral  *  fabs  (AUV_stern_lateral)  *  x_stern_lateral  )) 

-  rho2  *  L2  *  C_d0 

*  (  square  (SPEED_PER_RPM)  *   0.5  //  propeller  yaw 

*  (   AUV_port_rpm  *  f abs (AUV_port_rpm)  *  y_port_propeller 

*  port_propeller_ef f iciency 

+  AUV_stbd_rpm  *  fabs (AUV_stbd_rpm)  *  y_stbd_propeller 

*  stbd_propeller_eff iciency) 

//  ***  revision:   removed  (  -  U  *  fabs(U)  )  term  from  dissertation,  incorrect 
//  -  U  *  fabs(U) ) ; 

)  ; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

if  (TRACE  ||  TRACE_EOM  ||  (rhs  [YAW]  >=  MAX_YAW) )    //  Yaw  TRACE 
{ 

cout  «  "*  yaw  terml="  «   -  (I_y  -  I_x)  *  P*Q  +  I_xy  *  (P2  -  Q2) 

+  I_yz  *  P*R  -  I_xz  *  Q*R 
<<  endl; 

cout  «  "term2="  «    -   m  *  (  x_G  *  (  U*R  -  W*P)  -  y_G    *  (  -  V*R  +  W*Q) ) 
<<  endl ; 

cout  <<  " term3="  <<    +  rho2  *  L5   *  (   N_pq  *  P*Q   +  N_qr  *  Q*R 

+  N_r   *  R 

+  N_rr  *  R  *  fabs  (R) )   //  hovering  yaw  drag 
<<  endl ; 

cout  <<  "term4="  <<    +  rho2  *  L4   *  (  N_up  *  U*P   +  N_ur  *  U*R   +  N_vq  *  V*Q 

+  N_wp  *  W*P   +  N_wr  *  W*R) 
<<  endl; 

cout  <<  "term5="  <<  +  rho2  *  L3   *  (  N_uv  *  U*V   +  N_vw  *  V*W 

+  U*fabs(U)  *  N_uu_delta_rb  *  delta_rudder_bow 

-  U*fabs(U)  *  N_uu_delta_rs  *  delta_rudder_stern) 
<<  endl ; 

cout  <<  "term6="  <<   -  yaw_integral  <<  "  yaw_integral " 
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<<  endl; 


cout  <<  "term7="  <<   +  (x_G  *  Weight   -   revised_x_B  *  revisedBuoyancy) 

*  COSTHETA  *  sinPHI 
<<  endl; 


cout  <<  "term8="  <<   +  (y_G  *  Weight 
<<  endl; 


y_B  *  revisedBuoyancy)  *  sinTHETA 


cout  <<  "term9="  << 


(2.0  /  (24.0  *  24.0) ) 
//  each  thruster  2.0  lb  per  24V  signal  squared 
//  multiplied  by  respective  moment  arms 
*  (  (AUV_bow_lateral    *  fabs  (AUV_bow_lateral)    *  x_bow_lateral 


) 


+ (AUV_stern_lateral  *  fabs  (AUV_stern_lateral)  *  x_stern_lateral  )) 
<<  endl ; 

cout  <<  "terml0="  <<  -  rho2  *  L2  *  C_d0 

*  (  square  (SPEED_PER_RPM)  *   0.5  //  propeller  yaw 

*  (   AUV_port_rpm  *  fabs (AUV_port_rpm)  *  y_port_propeller 

*  port_propeller_ef f iciency 

+  AUV_stbd_rpm  *  f abs (AUV_stbd_rpm)  *  y_stbd_propeller 

*  stbd_propeller_eff iciency) 

removed  (  -  U  *  fabs (U)  )  term  from  dissertation,  incorrect 
•  -  U  *  fabs(U) ) ; 


// 

***  revision: 

// 

<<  endl; 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

II    debug  section.   selectively  set  rhs  values  to  zero  to  isolate  problems. 
//  also  see  zeroing  of  sway/heave/pitch/yaw  integrals. 

//  rhs  [SURGE]  =0.0 

/ /  rhs  [ SWAY  ]  =0.0 

//  rhs  [HEAVE]  =0.0 

//  rhs  [ROLL  ]  =  0.0 

//  rhs  [PITCH]  =0.0 

//  rhs  [YAW   ]  =  0.0 

MAX_ACCELERATIONS_EXCEEDED  = 

((rhs  [SURGE]  >=  MAX_SURGE)  (rhs  [SWAY  ]  >=  MAX_SWAY  ) 

(rhs  [HEAVE]  >=  MAX_HEAVE)  (rhs  [ROLL  ]  >=  MAX_ROLL  ) 

(rhs  [PITCH]  >=  MAX_PITCH)  (rhs  [YAW   ]  >=  MAX_YAW  ) ) ; 


if  (TRACE) 
{ 

cout  << 

cout  << 

cout  << 

cout  << 

cout  << 

cout  << 

} 

if  (TRACE  | |  TRACE_EOM) 
{ 


SURGE 

= 

1  << 

SWAY 

= 

'  << 

HEAVE 

= 

'  << 

ROLL 

= 

1  << 

PITCH 

= 

'  << 

YAW 

= 

1  << 

SURGE  <<  endl 

SWAY  <<  endl 

HEAVE  <<  endl 

ROLL  <<  endl 

PITCH  «  endl 

YAW  <<  endl 


cout 

<< 

" 

SURGE 

= 

"  << 

SURGE 

<< 

endl 

cout 

<< 

" 

SWAY 

= 

"  << 

SWAY 

<< 

endl 

cout 

<< 

" 

HEAVE 

= 

"  << 

HEAVE 

<< 

endl 

cout 

<< 

" 

ROLL 

= 

"  << 

ROLL 

<< 

endl 

■121- 


cout 

<< 

" 

PITCH 

= 

"  << 

PITCH 

<< 

endl; 

cout 

<< 

" 

YAW 

= 

"  << 

YAW 

<< 

endl; 

cout 

<< 

"rhs 

[SURGE] 

= 

"  << 

rhs 

[ SURGE ] 

<< 

endl, 

cout 

<< 

"rhs 

[SWAY  ] 

= 

"  << 

rhs 

[SWAY  ] 

<< 

endl , 

cout 

<< 

"rhs 

[ HEAVE ] 

= 

"  << 

rhs 

[HEAVE] 

<< 

endl, 

cout 

<< 

"rhs 

[ROLL  ] 

= 

"  << 

rhs 

[ROLL  ] 

<< 

endl, 

cout 

<< 

"rhs 

[PITCH] 

= 

"  << 

rhs 

[PITCH] 

<< 

endl , 

cout 

<< 

"rhs 

[YAW   ] 

= 

"  << 

rhs 

[YAW   ] 

<< 

endl , 

//  cout  <<  "mass_inverse: 

} 

if  (TRACE  | |  TRACE_EOM  | | 

{ 

cout  <<  "velocities: 


cout  <<  "RHS: 


} 


" ;    print_matrix6x6  (mass_inverse) ; 

MAX_ACCELERATIONS_EXCEEDED ) 

<"  <<  U  <<  " ,  "  <<  V  <<  " ,  "  <<  W  <<  " ,  " 

<<  P  <<  ",  "  <<  Q  <<  ",  "  <<  R  <<  ">"  <<  endl; 
" ;    print_matrix6  (rhs); 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

II    calculate  new  accelerations  matrix  using  mass_inverse  &  rhs,  print  // 

multiply6x6_6  (mass_inverse,  rhs,  new_acceleration) ; 


if  (TRACE  | |  TRACE_EOM) 
{ 

cout  <<  "Accelerations: 
} 

//  limit  accelerations  


print_matrix6  (new_acceleration) ; 


if  (CLAMP)   //  values  are  for  NPS  AUV 
{ 


clamp  (&  new_acceleration 
"new_acceleration 

clamp  (&  new_acceleration 
"new_acceleration 

clamp  (&  new_acceleration 
"new_acceleration 

clamp  (&  new_acceleration 
"new_acceleration 

clamp  (&  new_acceleration 
"new_acceleration 

clamp  (&  new_acceleration 
"new  acceleration 


SURGE ] 
SURGE] 
SWAY  ] 
SWAY  ] 
HEAVE] 
HEAVE] 

ROLL  ] 
ROLL  ] 
PITCH] 
PITCH] 
YAW  ] 
YAW   ] 


consider  parameterizing 


-MAX_SURGE 

-MAX_SWAY 

-MAX_HEAVE 

-MAX_ROLL 
-MAX_PITCH 
-MAX  YAW 


MAX_SURGE , 
MAX_SWAY  , 
MAX_HEAVE , 

MAX_ROLL  , 
MAX_PITCH, 
MAX  YAW   , 


•// 


//  find  velocities  by  integrating  averaged  accelerations  

//       (Heun  integration) 

(u_dot  +  new_acceleration  [SURGE] )  *  dt  +  U 

(v_dot  +  new_acceleration  [SWAY  ] )  *  dt  +  V 

(w_dot  +  new_acceleration  [HEAVE] )  *  dt  +  W 

(p_dot  +  new_acceleration  [ROLL  ] )  *  dt  +  P 

(q_dot  +  new_acceleration  [PITCH])  *  dt  +  Q 

(r_dot  +  new_acceleration  [YAW   ] )  *  dt  +  R 

//  find  velocities  by  integrating  instantaneous  accelerations 

//       (Euler  integration) 

//       (this  method  is  less  accurate  and  is  not  used,  although  at  small 

//       timesteps  the  difference  is  negligible) 


■// 


new_velocity 

[SURGE] 

= 

0 

5 

new_velocity 

[SWAY  ] 

= 

0 

5 

new_velocity 

[HEAVE] 

= 

0 

5 

new_velocity 

[ROLL  ] 

= 

0 

5 

new_velocity 

[PITCH] 

= 

0 

5 

new_velocity 

[YAW   ] 

= 

0 

5 
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//  new_velocity  [SURGE]  =  (new_acceleration  [SURGE] 

//  new_velocity  [SWAY  ]  =  (new_acceleration  [SWAY  ] 

//  new_velocity  [HEAVE]  =  (new_acceleration  [HEAVE] 

//  new_velocity  [ROLL  ]  =  (new_acceleration  [ROLL  ] 

//  new_velocity  [PITCH]  =  (new_acceleration  [PITCH] 

//  new_velocity  [YAW   ]  =  (new_acceleration  [YAW   ] 


dt  +  U 
dt  +  V 
dt  +  W 
dt  +  P 
dt  +  Q 
dt  +  R 


//  Note  that  surge  velocity  may  be  negative  under  model  constraints 

//  but  reverse  stability  is  a  problem.   Originally  clamped  non-negative. 

if  (CLAMP) 
{ 

clamp  (&  new_velocity  [SURGE],  -MAX_SURGE,  MAX_SURGE, 
"new_velocity  [SURGE]  velocity"); 

} 

//  update  UUVBody  state  accelerations  to  newly-calculated  values    // 

u_dot  =  new_acceleration  [SURGE] 

v_dot  =  new_acceleration  [SWAY  ] 

w_dot  =  new_acceleration  [HEAVE] 

p_dot  =  new_acceleration  [ROLL  ] 

q_dot  =  new_acceleration  [PITCH] 

r_dot  =  new_acceleration  [YAW   ] 

//  calculate  world  coordinate  system  linear  &  angular  velocities    // 

//   see  Cooke  Figure  10  for  corrections  to  Healey  equations  for  x/y/z_dot: 
//   also  Healey  course  notes  eqn  (26)  and  Frank-McGhee  corrected  paper  (A. 8) 

x_dot  =  AUV_oceancurrent_x 

+  U  *   cos  (PSI)  *  cos  (THETA) 

+  V  *  (cos  (PSI)  *  sin  (THETA)  *  sin  (PHI)  -  sin  (PSI)  *  cos (PHI)) 

+  W  *  (cos  (PSI)  *  sin  (THETA)  *  cos  (PHI)  +  sin  (PSI)  *  sin(PHI)); 
y_dot  =  AUV_oceancurrent_y 

+  U  *   sin  (PSI)  *  cos  (THETA) 

+  V  *  (sin  (PSI)  *  sin  (THETA)  *  sin  (PHI)  +  cos  (PSI)  *  cos (PHI)) 

+  W  *  (sin  (PSI)  *  sin  (THETA)  *  cos  (PHI)  -  cos  (PSI)  *  sin(PHI)); 
z_dot  =  AUV_oceancurrent_z 

-  U  *  sin  (THETA) 

+  V  *  cos  (THETA)  *  sin  (PHI) 

+  W  *  COS  (THETA)  *  COS  (PHI); 

phi_dot    =  P  +  Q  *  sin  (PHI)  *  tan  (THETA) 

+  R  *  cos  (PHI)  *  tan  (THETA); 

theta_dot  =     Q  *  cos  (PHI) 

-  R  *  sin  (PHI) ; 
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if   (cos  (THETA)  ==  0.0) 
{ 

cout  <<  "UUVBody : : integrate_equations_of_motion  ():   "        <<  endl; 

cout  <<  "    cos  (THETA)  ==  0.0  so  psi_dot  set  equal  to  zero."  <<  endl; 

psi_dot  =  0.0; 
} 
else  psi_dot  =  (Q  *  sin  (PHI)  +  R  *  cos  (PHI))  /  cos  (THETA); 

Vector3D  linear_rates  =   Vector3D  (x_dot,  y_dot,  z_dot) ; 

if  (TRACE  | |  TRACE_EOM) 

{ 

cout  <<  endl ; 

cout  <<  "<x_dot,  y_dot,  z_dot>         =  "  <<  linear_rates  <<  endl; 

cout  <<  "  magnitude  =  "  <<  linear_rates .magnitude  () 

<<  endl; 
} 

Vector3D  euler_rates  =   Vector3D  (phi_dot,  theta_dot,  psi_dot) ; 

if  (TRACE  | |  TRACE_EOM) 

{ 

cout  <<  "<phi_dot,  theta_dot,  psi_dot>  =  "  <<  euler_rates  <<  endl; 

cout  <<  "  magnitude  =  "  <<  euler_rates .magnitude  () 

<<  endl ; 
} 

//  calculate  world  coordinate  system  homogenous  transform  matrix    // 

Hmatrix  Hincremental  =  Hmatrix  ();  //  default  initialization 
Hincremental . set_orientation  (  P  *  dt,  Q  *  dt,  R  *  dt  ); 
Hincremental. rotate       (  PHI,     THETA,   PSI     ); 

double  omega_x  =  Hincremental .phi_value  () 
double  omega_y  =  Hincremental . theta_value  ( ) 
double  omega_z  =  Hincremental .psi_value    () 

Vector3D  world_rates  =   Vector3D  (omega_x,  omega_y,  omega_z) ; 

if  (TRACE  | |  TRACE_EOM) 

{ 

cout  <<  "<omega_x,  omega_y,  omega_z>  =  "  <<  world_rates  <<  endl; 

cout  <<  "  magnitude  =  "  <<  world_rates .magnitude  () 

<<  endl ; 
} 

Hmatrix  Hrevisedl  =  Hmatrix  ();    //  default  initialization 

Hrevisedl . incremental_rotation     (  phi_dot,  theta_dot,  psi_dot,  dt  ); 

Hrevisedl . incremental_translation  (  U,  V,  W,  dt  ); 

Hmatrix  Hproductl  =  Hprevious  *  Hrevisedl; 

Hproductl . incremental_translation  (AUV_oceancurrent_x, 

AUV_oceancurrent_y , 
AUV_oceancurrent_z ,  dt)  ; 

Hprevious  =  Hproductl; 

//  translate  and  rotate  and  update  time  in  RigidBody  state  // 

//  note  world  coordinate  system  is  used  by  RigidBody: 

set_angular_velocities  (phi_dot,  theta_dot,  psi_dot) ; 

set_linear_velocities  (   x_dot,      y_dot,    z_dot)  ; 

set_time_of_posture  (current_uuv_time) ; 

update_Hmatrix  (dt) ; 
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if  (TRACE) 
{ 


cout  <<  " incremental  hmatrix 
Hincremental . pr int_hmatrix  ( ) 
cout  <<  "revisedl  hmatrix  =  " 
Hrevisedl .print_hmatrix  ( ) ; 
cout  <<  "productl  hmatrix  =  " 
Hproductl .print_hmatrix  ( )  ; 

cout  <<  "original  hmatrix  =  " 
hmatrix. print_hmatrix  (); 


if  (TRACE)   cout  <<  "substituting  productl  hmatrix"  <<  endl , 
hmatrix  =  Hproductl ; 


// 


//  Save  body-coordinate-system  velocities  for  the  next  loop: 


U  =  new_velocity  [SURGE] 

V  =  new_velocity  [SWAY  ] 

W  =  new_velocity  [HEAVE] 

P  =  new_velocity  [ROLL  ] 

Q  =  new_velocity  [PITCH] 

R  =  new_velocity  [YAW   ] 


//  cout  <<  "world  U 

//  cout  <<  "world  V  =' 

//  cout  <<  "world  W  =' 

//  cout  <<  "world  P  =' 

//  cout  <<  "world  Q 

//  cout  <<  "world  R  =' 


"  << 

u 

<<  " 

,  x_dot 

= 

<< 

x  dot 

<< 

endl 

"  << 

V 

<<  " 

/  y_dot 

= 

<< 

y_dot 

<< 

endl 

"  << 

w 

<<  " 

,  z_dot 

= 

<< 

z  dot 

<< 

endl 

"  << 

P 

<<  " 

,  phi_dot 

= 

<< 

phi_dot 

<< 

endl 

"  << 

Q 

<<  " 

,  theta_dot 

= 

<< 

theta  dot 

<< 

endl 

"  << 

R 

<<  " 

,  psi_dot 

= 

<< 

psi_dot 

<< 

endl 

//  

//  update  all  hydrodynamics-model-provided  state  variables  in  AUV_globals .h 
//        prior  to  retransmittal  to  AUV  via  AUVsocket 


AUV  time 


current_uuv_time;  //  mission  time 


AUV_x 

AUV_y 

AUV_z 

AUV_phi 

AUV_theta 

AUV_psi 


= 

x_value     ( ) 

// 

= 

y_value      ( ) 

// 

= 

z_value      ( ) 

// 

= 

phi_value    ( ) 

// 

= 

theta_value  ( ) 

// 

= 

psi_value    () 

// 

x  position  in  world  coordinates 
y  position  in  world  coordinates 
z  position  in  world  coordinates 
roll  posture  in  world  coordinates 
pitch  posture  in  world  coordinates 
yaw   posture  in  world  coordinates 


AUV_speed=new_velocity  [SURGE];  //   paddlewheel  speed  =  u  =  surge 


AUV_u 
AUV_v 
AUV_w 
AUV_p 
AUV_q 
AUV_r 


new_velocity 
new_velocity 
new_velocity 
new_velocity 
new_velocity 
new_velocity 


[SURGE] 
[SWAY  ] 
[HEAVE] 
[ROLL  ] 
[PITCH] 
[YAW   ] 


//  surge  linear  velocity  along  x-axis 

//  sway  linear  velocity  along  y-axis 

//  heave  linear  velocity  along  x-axis 

//  roll  angular  velocity  about  x-axis 

//  pitch  angular  velocity  about  y-axis 

//  yaw  angular  velocity  about  z-axis 


AUV_u_dot 
AUV_v_dot 
AUV_w_dot 
AUV_p_dot 
AUV_q_dot 
AUV_r_dot 


=  u_dot 
=  v_dot 
=  w_dot 
=  p_dot 
=  q_dot 
=  r  dot 


//  linear  acceleration  along  x-axis 

//  linear  acceleration  along  y-axis 

//  linear  acceleration  along  x-axis 

//  angular  acceleration  about  x-axis 

//  angular  acceleration  about  y-axis 

//  angular  acceleration  about  z-axis 


AUV  x  dot 


x_dot; 


// 


Euler  velocity  along  North-axis 
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AUV_y_dot     =  y_dot; 

// 

AUV_z_dot     =  z_dot; 

// 

AUV_phi_dot    =  phi_dot; 

// 

AUV_theta_dot  =  theta_dot; 

// 

AUV_psi_dot    =  psi_dot; 

// 

Euler  velocity  along  East-axis 

Euler  velocity  along  Depth-axis 

Euler  rotation  rate  about  North-axis 

Euler  rotation  rate  about  East-axis 

Euler  rotation  rate  about  Depth-axis 


divetracker_rangel  =  sqrt  (sgr  (AUV_x  -  DiveTrackerl_x)  + 

sqr  (AUV_y  -  DiveTrackerl_y)  + 
sgr  (AUV_z  -  DiveTrackerl_z) ) ; 


divetracker_range2 


sgrt  (sgr  (AUV_x  -  DiveTracker2_x)  + 
sgr  (AUV_y  -  DiveTracker2_y)  + 
sgr  (AUV_z  -  DiveTracker2_z) )  ; 


// 

//set  value  of  doppler  sonar  outputs 
// 

//doppler  speed  over  ground  in  meters /sec 
doppler_sog_u  =  U  *  0.3048; 
doppler_sog_v  =  V  *  0.3048; 

//doppler  speed  through  water  in  meters /sec 
doppler_stw_u  =  doppler_stw_u  *   0.3048; 
doppler_stw_v  =  doppler_stw_v  *   0.3048; 

//doppler  altitude  returns  height  of  AUV  above  bottom  in  meters,  I  assume  total  depth  of 
100  meters 

doppler_altitude  =  100.0  -  AUV_z; 

if  (FALSE  &&  TRACE_EOM  &&  MAX_ACCELERATIONS_EXCEEDED) 
{ 

char   user_pause; 

cout  <<  "====  Hit  enter  to  continue...  ==-="; 

cin   >>  user_pause; 

cout  <<  endl ; 
} 

return;  //  integrate_eguations_of_motion  ()  complete 
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APPENDIX  B.  VIRTUAL  ENVIRONMENT  JAVA/VRML  CODE 


1.        Java  Source  Code 

This  appendix  includes  the  files  needed  for  the  Phoenix  AUV  dynamics  to  run  in  Java  with  the 
virtual  environment  done  in  VRML.  Since  the  functionality  of  the  C++  and  Java  version  are  the  same 
the  actual  source  code  is  not  included.  The  source  code  is  freely  distributed  at 
http://www.stl.nps.navy.mil/~auv.  Please  feel  free  to  download  a  complete  version  of  the  code  if  it  is 
required.  The  complete  list  of  Java  files  needed  to  run  the  virtual  environment  follows: 


dynamics. Java 

AUVglobals.java 

SonarModel.java 

AUVmodel.java 

RigidBody.java 

Hmatrix.java 

MathU.java 


UUVBody.java 

UUVmodel.java 

AUVsocket.java 

FlowFileReader.j  ava 

DISNetworkedRigidBody.java 

Vector3D.java 

Console  Java 


Additionally,  the  DIS-Java-VRML  library  is  required  to  compile  the  program.  This  can  be 
obtained  free  of  charge  at  http://www.stl.nps.navy.mil/dis-java-vrml. 
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2.        AUVvirtual.wri 

#VRML  V2.0  utf8 

#This  file  creates  a  Virtual  world  for  the  Phoenix  AUV 
#Author:   Kevin  Byrne 
#Date  :    28  January  1998 

############################################ 
#This  is  the  externproto  to  link  in  DIS  pdu ' s 

EXTERNPROTO  EspduReadTransf ormTrace  [ 

field  SFString      marking  #  0..11  character  label  for 

entity 

field  SFTime  readlnterval  #  seconds  between  DIS  updates 

field  SFString      address  #  multicast  address  or 

"unicast" 

field  SFInt32  port  #  port  number 

exposedField  MFNode  children 

field  SFVec3f  translation 

field  SFRotation    rotation 

exposedField  SFVec3f  scale 

exposedField  SFRotation    scaleOrientation 

field  SFVec3f  bboxCenter 

field  SFVec3f  bboxSize 

exposedField  SFVec3f  center 

event In  MFNode  addChildren 

event In  MFNode  removeChildren 

]  [  "EspduReadTransform.wri" 

" . . /JavaViaScriptNode/EspduReadTransf orm. wrl"  #  local  or  remote  URLs  for  the 
EXTERNPROTO 

"http: //www. stl .nps .navy.mil/dis-java-vrml/mil/navy/nps/JavaViaScriptNode/EspduReadTransfo 
rm.wrl" 

] 

EspduReadTransf ormTrace  { 

marking       "Phoenix  AUV" 

readlnterval  2  #  seconds  between  DIS  reads 

#  do  not  modify  address /port  while  using   unicast-only  browser,  run  bridge  instead 

#  address  "224.2.244.141"      #  NPS  AUV  exercise  default, 
multicast 

#  port  3111  #  NPS  AUV  exercise  default 

children  Inline  { 

url     [       "phoenix_auv.wri" 

" http : / /web . nps . navy . mi 1 / -kmbyrne / AUVvw/phoenix_auv . wr 1 " 
] 
} 


translation   2-2  0        #  offset  for  initial  location/orientation, 


} 


#End  of  Proto 
############################################################ 
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Group  { 

children  [ 

#This  Section  states  Navigation  info 
Navigationlnfo   { 

type    "EXAMINE"        #In  the  end  should  be  FLY 
speed   10.0 

avatarSize     [0.26,  1.6,  0.75] 
}, 

#This  section  adds  a  background  to  the  scene 
Background  { 
skyColor  [ 

0.0  0.2  0.7, 
0.0  0.5  1.0, 
0.4  0.8  1.0   ] 
skyAngle  [1.309,  1.571] 
}, 


#This  Section  creates  the  Ocean  Floor 
Transform   { 
translation  -75.0  -30.0  -75.0 
children  Shape  { 

appearance  Appearance  { 

material  Material  { 

ambientlntensity  0 
diffuseColor  0.3  0 
specularColor  0.75 
shininess  0.10 
} 
} 

geometry  ElevationGrid  { 
xDimension  15 
zDimension  15 
xSpacing  10 
zSpacing  10 
solid       FALSE 

creaseAngle  0.785 
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.0 

0. 

.0 

0, 

.0 

0 

.0 

0 

.0 

0, 

.0 

0, 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0. 

.0 

0, 

.0 

0 

.0 

0 

.0 

0 

.0 

0, 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0, 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0. 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0 

.0 

0, 

.0 

0, 

.0 

0, 

.0 

}, 


#This  section  adds  the  sea  surface 
#It  uses  an  indexed  face  set 
Shape  { 

appearance  Appearance  { 

material  Material  { 

ambientlntensity  0.70 
diffuseColor  0.0  0.0  1.0 


specularColor  0.0  0.0  1.00 


129- 


shininess  0.10 
transparency  0 . 3 
} 
} 
geometry  IndexedFaceSet  { 

coord   Coordinate  { 

point  [  -75   0   75, 
-75   0  -75, 
75   0  -75, 
75   0   75,] 
} 

coordlndex  [   0,  1,  2,  3,  ] 
solid  FALSE 


}, 

#This  section  adds  the  Sun 
DirectionalLight  { 
direction  0.0  -1.0  0.0 
}, 

#This  Section  places  a  688  Class  Submarine  in  the  scene 
Transform  { 

translation  0.0  -5.0  40.0 
rotation     0.0  1.0  0.0  3.142 
#This  sub  must  be  scaled  down  from  600  M  to  -100  M 
scale  0.1666  0.1666  0.1666 
children  [ 

Inline  { 

bboxSize  500.0  300.0  300.0 
url  "688.wri" 
} 
] 
}, 

#This  transform  places  the  oil  rig  in  the  scene 
Transform  { 

translation  -45.0  7.0  -10.0 
children  [ 
Inline   { 

bboxSize  200.0  200.0  200.0 
url  "oil_rig.wri" 


} 


] 


}, 


#This  places  a  tube  on  the  sea  floor 
Transform  { 

translation  0.0  -30.0  0.0 
rotation     1.0  0.0  0.0  1.571 
children   [ 
Shape  { 

appearance  Appearance  { 
material  Material  { 

diffuseColor  0.8  1.0  0.0 
} 
} 

geometry  Cylinder  { 

height  6.0 

top     FALSE 

bottom  FALSE 
} 
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] 

}, 
] 
} 

#end  of  file  AUVvirtual.wri 
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3.        Oil_rig.wri 

#VRML  V2 .0  utf8 

#This  file  creates  an  oil  rig  for  the  Phoenix  AUV  VW 
#Author:   Kevin  Byrne 
#Date  :    28  January  1998 


Navigationlnfo  { 

type  [  "EXAMINE"  "ALL"  ] 


} 

Viewpoint  { 

position  17  35  0 
orientation  0  10  0 
description  "On  Oil  Rig" 

} 

Group  { 

children  [ 

#This  creates  the  left   forward  leg 
Transform  { 

translation  0.0  -10.0  0.0 
children   [ 
Shape  { 

appearance  Appearance  { 

material  DEF  blueMetal  Material  { 

diffuseColor  0.4  0.4  1.0 
} 
} 

geometry  DEF  Leg  Cylinder  { 

radius  3 . 0 

height  55.0 
} 


}, 

#Back  Left  Leg 
Transform  { 

translation   0.0  -10.0  -35.0 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  blueMetal 
} 

geometry  USE  Leg 
} 
] 
}, 

#Back  Right  Leg 
Transform  { 

translation   35.0  -10.0  -35.0 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  blueMetal 
} 


132- 


geometry  USE  Leg 
} 


}, 


#Front  Right  Leg 
Transform  { 

translation   35.0  -10.0  0.0 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  blueMetal 
} 

geometry  USE  Leg 


>, 

#This  creates  the  left   forward  crossbeam 
Transform  { 

translation   17.5  10.0  0.0 
rotation      0.0  0.0  1.0  1.2 
children   [ 
Shape  { 

appearance  Appearance  { 

material  DEF  white  Material  { 

diffuseColor  1.0  1.0  1.0 
} 
} 

geometry  DEF  CrossLeg  Cylinder  { 

radius  0 . 8 

height  3  8.0 
} 


} 


#Left  forward  cross  beam  2 
Transform  { 

translation   17.5  10.0  0.0 
rotation     0.0  0.0  1.0   -1.2 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  white 
} 

geometry  USE  CrossLeg 


}, 


#Left  forward  cross  beam  3 
Transform  { 

translation   0.0  10.0  -17.5 
rotation     1.0  0.0  0.0   1.2 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  white 
} 
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geometry  USE  CrossLeg 
} 


>, 


#Left  forward  cross  beam  4 
Transform  { 

translation   0.0  10.0  -17.5 
rotation     1.0  0.0  0.0   -1.2 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  white 
} 

geometry  USE  CrossLeg 
} 


#Left  forward  cross  beam  5 
Transform  { 

translation   35.0  10.0  -17.5 
rotation     1.0  0.0  0.0   1.2 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  white 
} 


geometry  USE  CrossLeg 
} 


}, 


#Left  forward  cross  beam  6 
Transform  { 

translation   35.0  10.0  -17.5 
rotation     1.0  0.0  0.0   -1.2 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  white 
} 

geometry  USE  CrossLeg 


#Left  forward  cross  beam  7 
Transform  { 

translation   17.5  10.0  -35.0 
rotation     0.0  0.0  1.0   1.2 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  white 
} 


geometry  USE  CrossLeg 
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} 
] 
}, 

#Left  forward  cross  beam  8 
Transform  { 

translation   17.5  10.0  -35.0 
rotation      0.0  0.0  1.0   -1.2 
children   [ 
Shape  { 

appearance  Appearance  { 

material  USE  white 
) 

geometry  USE  CrossLeg 


}, 

#This  creates  the  bottom  platform 
Transform  { 

translation   17.5  17.5  -17.5 
children   [ 
Shape  { 

appearance  Appearance  { 
material  Material  { 

diffuseColor  1.0  0.2  0.2 
} 
} 

geometry  Box  { 

size  50.0  2.0  50. 0 
} 
} 
] 
>, 

#This  places  a  simple  box-like  building  on  the  oil  rig 
Transform  { 

translation   27.5  22.5  -17.5 
children   [ 
Shape  { 

appearance  Appearance  { 
material  Material  { 

diffuseColor  1.0  1.0  0.0 
} 
} 

geometry  Box  { 

size  15.0  8.0  10.0 
} 


} 

#This  places  a  second  simple  box-like  building  on  the  oil  rig 
Transform  { 

translation   5.0  21.5  -17.5 
children   [ 
Shape  { 

appearance  Appearance  { 
material  Material  { 

diffuseColor  0.4  1.0  0.4 
} 
} 
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geometry  Box  { 

size  10.0  6.0  10.0 
} 
} 


} 


]    #  end  of  oilRig  group  children 
}   #  end  of  oilRig  group 

#end  of  file  oil_rig.wri 
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4.        688.wri 


#VRML   V2.0    utf8 

#This  file  creates  a  submarine 

#Author:   Kevin  Byrne 

#Date  :    2  Dec  1997 


#This  Section  builds  a  688  Class  Submarine 
Transform  { 


children  [ 

#The  Submarine  Hull 

Group  { 

children      [ 

Navigationlnfo  { 
avatarSize 

}, 

Viewpoint  { 
position 
orientation 
f ieldOfView 
description 

}, 

Viewpoint  { 
position 
orientation 
f ieldOfView 
description 

}, 

Viewpoint  { 
position 
orientation 
f ieldOfView 
description 

}, 

Viewpoint  { 
position 
orientation 
f ieldOfView 
description 

}, 


[  0.3,  1.6,  0.75  ] 


-600  0  0 

0  1.0  0  -1.571 

0.8 

"Upper  Foward  End  of  688,  looking  Aft' 


-40  20  -110 

0  1.0  0  3.14 

0.95993 

"Upper  STBD  Side  of  688,  looking  to  Port' 


350  50  10 

0  1.0  0  1.571 

0.8 

"Upper  Aft  End  of  688,  looking  Fwd' 


-40  20  120 

0  0  0  0 

0.95993 

"Upper  Port  Side  of  688,  looking  to  STBD' 


Viewpoint  { 
position 
orientation 
f ieldOfView 
description 

}, 

Viewpoint  { 
position 
orientation 
fieldOfView 
description 

}, 


-350  -60  10 

0  1.0  0  -1.571 

0.8 

"Lower  Foward  End  of  688,  looking  Aft' 


-80  -20  -110 

0  1.0  0  3.14 

0.95993 

"Lower  STBD  Side  of  688,  looking  to  Port1 


Viewpoint  { 

position 

350  -50  10 

orientation 

0  1.0  0  1.571 

f ieldOfView 

0.8 

description 
}, 
Viewpoint  { 

"Lower  Aft  En 

position 

-80  -20  120 

orientation 

0  0  0  0 

f ieldOfView 

0.95993 
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description    "Lower  Port  Side  of  688,  looking  to  STBD" 
}, 

Transform  { 

rotation     0.577417  -0.577317  -0.577317   4.18889 
center        0  2.5  10 
children 

Shape  { 

appearance  Appearance  { 

material  DEF  _688_Hull  Material  { 
ambientlntensity       0.1 
diffuseColor     0.1  0.1  0.1 
specularColor    0.1  0.1  0.1 
} 

} 


teometry       IndexedFaceSet    { 

coord  Coordinate    { 

point             [              1.73    -160    5 

.33, 

0    -162.5    4.92, 

0    -160    5.6, 

0.25    -165    4.23, 

0.25    -167.5    3.55, 

0.46    -175    1.43, 

0    -172.5    2.18, 

0    -175    1.5, 

5.6    -160    0, 

4.95    -162.5    0, 

5.33    -160    1.73, 

4.23    -165    0.25, 

3.55    -167.5    0.25, 

1.43    -175    0.46, 

2.18    -172.5    0, 

1.5    -175    0, 

18    -172.5    10, 

17.8    -170    10, 

18.2    -170    10, 

18.2    -167.5    10, 

17.8    -167.5    10, 

18    -166    10, 

0    -172.5    15, 

0    -166    15, 

0.2    -170    15, 

17.8    -170    0.2, 

17.8    -167.5    0.2, 

18    -166    0, 

18.2    -170    0, 

18    -172.5    0, 

0.2    -167.5    15, 

4.53    -160    3.29, 

0.88    -175    1.21, 

3.29    -160    4.53, 

-3.29    -160    4.53, 

-0.46    -175    1.43, 

-0.88    -175    1.21, 

-4.53    -160    3.29, 

-1.21    -175    0.88, 

-5.33    -160    1.73, 

-1.43    -175    0.46, 

-0.25    -165    4.23, 

-0.2    -167.5    15, 

-0.25    -167.5    3.55, 

-0.2    -170    15, 

-4.23    -165    0.25, 

-17.8    -167.5    0.2, 

-4.95    -162.5    0, 

-3.55    -167.5    0.25, 

-2.18    -172.5    0, 

-18    -172.5    0, 

-18.2    -170    10, 

-18.2    -170    0, 

-18.2    -167.5    10, 

-18.2    -167.5    0, 

-18    -166    10, 

-18    -166    0, 

-17.8    -167.5    10, 

-17.8    -170    10, 

-17.8    -170    0.2, 

-18    -172.5    10, 

-1.5    -175    0, 

-5.6    -160    0, 

-1.73    -160    5.33, 

-1.73    -160    -5.33, 

0    -162.5    -4.92, 

0    -160    -5.6, 

-0.25    -165    -4.23, 

-0.25    -167.5    -3.55 

-0.46    -175    -1.43, 

0    -172.5    -2.18, 

0    -175    -1.5, 

-5.33    -160    -1.73, 

-4.23    -165    -0.25, 

-3.55    -167.5    -0.25 

-1.43    -175    -0.46, 

-18    -172.5    -10, 

-17.8    -170    -10, 

-18.2    -170    -10, 

-18.2    -167.5    -10, 

-17.8    -167.5    -10, 

-18    -166    -10, 

0    -172.5    -15, 

0    -166    -15, 

-0.2    -170    -15, 

-17.8    -170    -0.2, 

-17.8    -167.5    -0.2, 

-0.2    -167.5    -15, 

-4.53    -160    -3.29, 

-0.88    -175    -1.21, 

-3.29    -160    -4.53, 
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3.29  -160  -4.53, 

0.46  -175  -1.43, 

0.88  -175  -1.21, 

4.53  -160  -3.29, 

1.21  -175  -0.88, 

5.33  -160  -1.73, 

1.43  -175  -0.46, 

0.25  -165  -4.23, 

0.2  -167.5  -15, 

0.25  -167.5  -3.55 

0.2  -170  -15, 

4. 

23  -165  -0.25, 

17.8  -167.5  -0.2, 

3.55  -167.5  -0.25 

18.2  -170  -10, 

18.2  -167.5  -10, 

18.2  -167.5  0, 

18  -166  -10, 

17.8  -167.5  -10, 

17.8  -170  -10, 

17.8  -170  -0.2, 

18  -172.5  -10, 

1.73  -160  -5.33, 

0  180  0, 

1.6  179.6  0, 

1. 

52  179.6  0.5, 

1.29  179.6  0.94, 

0.94  179.6  1.29, 

0.5  179.6  1.52, 

0  179.6  1.6, 

3.42  178  1.1, 

2. 

91  178  2.11, 

2.11  178  2.91, 

1.1  178  3.42, 

3.6  178  0, 

5.6  176  0, 

5.33  176  1.73, 

3.29  176  4.53, 

1.73  176  5.33, 

0  176  5.6, 

0  178  3.6, 

8.3  172  0, 

6.71  172  4.88, 

4.53  176  3.29, 

4.88  172  6.71, 

0  172  8.3, 

11.2  164  0, 

7. 

9  172  2.56, 

9.06  164  6.58, 

6.58  164  9.06, 

2.56  172  7.9, 

0 

164  11.2, 

14  152  0, 

10.65  164  3.46, 

13.31  152  4.33, 

8.23  152  11.33, 

4.33  152  13.31, 

3.46  164  10.65, 

0  152  14, 

14.27  140  4.64, 

12.14  140  8.82, 

11.33  152  8.23, 

8.82  140  12.14, 

4.64  140  14.27, 

15  140  0, 

14.93  128  4.85, 

12.7  128  9.23, 

9.23  128  12.7, 

4.85  128  14.93, 

0  140  15, 

15.7  128  0, 

15.07  116  4.89, 

12.82  116  9.32, 

9.32  116  12.82, 

4.89  116  15.07, 

0  128  15.7, 

15.85  116  0, 

16  100  0, 

12.94  100  9.4, 

9.4  100  12.94, 

0  100  16, 

0  116  15.85, 

15.22  90  4.94, 

15.22  100  4.94, 

12.94  90  9.4, 

9. 

4  90  12.94, 

4.94  90  15.22, 

4.94  100  15.22, 

0  90  16, 

16  60  0, 

15.22  30  4.94, 

15.22  60  4.94, 

12.94  30  9.4, 

12.94  60  9.4, 

9.4  30  12.94, 

9. 

4  60  12.94, 

4.94  30  15.22, 

4.94  60  15.22, 

0  30  16, 

0  60  16, 

16  30  0, 

15.22  0  4.94, 

12.94  0  9.4, 

9.4  0  12.94, 

4.94  0  15.22, 

0  0  16, 

16  0  0, 

15.22  -30  4.94, 

12.94  -30  9.4, 

9.4  -30  12.94, 

4.94  -30  15.22, 

0  -30  16, 

16  -30  0, 

15.22  -60  4.94, 

12.94  -60  9.4, 

9.4  -60  12.94, 

4.94  -60  15.22, 

0  -60  16, 

16  -60  0, 

15.22  -80  4.94, 

12.94  -80  9.4, 

9.4  -80  12.94, 

4.94  -80  15.22, 

0  -80  16, 

16  -80  0, 

15.7  -90  0, 

14.93  -90  4.85, 

9.23  -90  12.7, 

4.85  -90  14.93, 

0  -90  15.7, 
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0  -110  15, 

13.31  -120  4.33, 
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0  -120  14, 

9.06  -139  6.58, 

6.58  -139  9.06, 

11.2  -139  0, 

4.88  -150  6.71, 

0  -139  11.2, 

6.71  - 

-150  4.88, 

2.56  -150  -7.9, 

4.88  -150  -6.71, 

7.9  -150  -2.56, 

0  -139  -11.2, 

9.06  -139  -6.58, 

4.33  -120  -13.31 

8.23  ■ 

-120  -11.33, 

13.31  -120  -4.33 

8.82  -110  -12.14 

14.27  -110  -4.64 

0  -110  -15, 

12.7  -90  -9.23, 

4.94  -80  -15.22, 

9.4  -80  -12.94, 

15.22  -80  -4.94, 

0  -80  -16, 

12.94  -60  -9.4, 

4.94  -30  -15.22, 

9.4  -30  -12.94, 

15.22  -30  -4.94, 

0  -30  -16, 
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563, 

,  560 

565, 

,  526 

566, 

,  563 

568, 

,  566 

569, 

,  214 
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559, 
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557, 

-1 

220, 

-1 

564, 

-1 

562, 

-1 

567, 

-1 

565, 

-1 

208, 

-1 

572, 

-1 

574, 

-1 

575, 

-1 

577, 

-1 

196, 

-1 

580, 

-1 

582, 

-1 

583, 

-1 

585, 

-1 

190, 

-1 

401, 

-1 

405, 

-1 

587, 

-1 

589, 

-1 

172, 

-1 

592, 
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590, 

-1 

591, 

-1 

597, 
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166, 
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600, 
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599, 

-1 

605, 
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142, 
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608, 

-1 

606, 

-1 

607, 

-1 

613, 

-1 

130, 

-1 

616, 

-1 

614, 

-1 

619, 

-1 

617, 

-1 

131, 

-1 

624, 

-1 

626, 

-1 

}, 

#The  Propeller 
Transform  { 


translation  178.5  -7.5  9.5 

rotation     0.0  0.0  1.0  1.571 
scale       2.5  2.5  2.5 
children  [ 
DEF  propel ler_movement  Transform  { 
rotation  1.0  0.0  0.0  0.0 
children 
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hub 


Group  { 
children  [ 

#The  center  hub  of  the  propeller 
Shape  { 

appearance  DEF  Bronze  Appearance  { 
material  Material  { 

diffuseColor  1.0  1.0  0.0 
}   #end  material 
}     #end  appearence 
geometry  Cylinder  { 

radius  0 . 7 
height  0.5 
}   #  end  geometry 
} ,     #end  shape 

#Blade  1,  oriented  to  stick  out  of  the   right  side  of  the 

DEF  Blade  Transform   { 
rotation       1.0    0.0    0.0   1.048 
translation     2.0    0.0    0.0 
scale  2.0    0.1   0.5 

children    Shape  { 

appearance   USE  Bronze 

geometry  Sphere  { } 
}    #end  shape 

} ,         tend  transform 

#Blade  2 

Transform  { 

rotation  0.0  1.0  0.0  1.26 

children  USE  Blade 

}, 

#Blade  3 

Transform  { 

rotation  0.0  1.0  0.0  2.52 

children  USE  Blade 


#Blade  4 

Transform  { 

rotation  0.0  1.0  0.0  3.78 

children  USE  Blade 

}, 

#Blade  5 

Transform  { 

rotation  0.0  1.0  0.0  5.04 

children  USE  Blade 

} 

]       #  end  of  children  in  group 
}  #  end  of  Propeller  Group 

}  ,      #end  of  propeller_position  Transform 
DEF  Blade_Clock  TimeSensor  { 
cyclelnterval  3.0 

startTime     1.0 
loop  TRUE 

}, 
DEF  Blade_Path  Orientationlnterpolator  { 

key  [0.0,  0.1,  0.2,  0.3,  0.4,  0.5,  0.6,  0.7,  0.8,  0.9] 
keyValue  [0.0  1.0  0.0  0.0, 
0.0  1.0  0.0  0.628, 
0.0  1.0  0.0  1.256, 
0.0  1.0  0.0  1.884, 
0.0  1.0  0.0  2.512, 
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0.0  1.0  0.0  3.14, 
0.0  1.0  0.0  3.768, 
0.0  1.0  0.0  4.396, 
0.0  1.0  0.0  5.024, 
0.0  1.0  0.0  5.652  ] 


#The  Vortex  Dissipater 
Transform  { 

translation  182.5  -7.5  9.5 
rotation     0.0  0.0  1.0  -1.571 
children  Shape  { 

appearance  Appearance   { 
material  USE   688  Hull 


} 


geometry  Cone  { 
height  6.0 
bottomRadius  1.7 


} 


#This  section  creates  the  periscope 
Transform  { 

translation  -76.0  32.0  10.0 

children  [ 

Shape   { 


appearance  Appearance  { 

material   DEF  Scope_color  Material  { 
diffuseColor    0.75  0.75  0.75 
} 
} 

geometry  Cylinder  { 
radius  0 . 2 
height  9.0 
} 
}, 
Transform  { 

translation  -0.2  4.3  0.0 
scale  1.2  1.0  0.80 
children  Shape   { 

appearance  Appearance  { 

material  USE  Scope_color 

} 

geometry  Cylinder  { 
radius  0 . 3 
height  0.4 
} 
} 
} 


ROUTE  Blade_Clock.fraction_changed  TO  Blade_Path. set_fraction 
ROUTE  Blade_Path. value_changed  TO  propel ler_movement . set_rotation 
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5.        Phoenix_auv.wri 

#VRML  V2 .0  utf8 

#Model  of  the  Naval  Postgraduate  School  Center  for  Autonomous 

#  Underwater  Vehicle  (AUV)  Research's  "Phoenix"  AUV. 

#  Authors:  Martin  Whitfield,  Don  Brutzman,  Kevin  Byrne 

Viewpoint  { 

position  0  0  2 

orientation  0  10  0 

description  "Stbd  Beam" 
} 

Viewpoint  { 

position  2  0  2 

orientation  0  10  .707 

description  "Stbd  Bow" 
} 

Viewpoint  { 

position  2  0  0 

orientation  0  1  0  1.4 

description  "Bow" 
} 

Viewpoint  { 

position  2  0-2 

orientation  0  10  2.3562 

description  "Port  Bow" 
} 

Viewpoint  { 

position  0  0-2 

orientation  0  10  3.14159267 

description  "Port  Beam" 
} 

Viewpoint  { 

position  -2  0  -2 

orientation  0  10  3.9270 

description  "Astern  Port" 
} 

Viewpoint  { 

position  -2  0  0 

orientation  0  1  0  -1.4 

description  "Astern" 
} 

Viewpoint  { 

position  -2  0  2 

orientation  0  10  -.707 

description  "Astern  Stbd" 
} 

Viewpoint  { 

position  0  0  2 

orientation  0  10  0 

description  "Stbd  Beam" 
} 

Viewpoint  { 

position  0  1.5  1.5 
orientation  10  0  -.707 
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} 


description  "Above  Stbd  Beam" 


Viewpoint  { 

position  2  2  2 

orientation  -.6786  .6786  -.2811  1.0961 

description  "Above  Stbd  Bow" 

} 

Viewpoint  { 

position  2  2  0 

orientation  -.3574  .8629  .3574  1.7178 

description  "Above  Bow" 
} 

Viewpoint  { 

position  2  2-2 

orientation  -.3780  .9125  .1566  2.4189 

description  "Above  Port  Bow" 

} 

Viewpoint  { 

position  0  2-2 
orientation  10  0  3.9270 
description  "Above  Port  Beam" 

} 

Viewpoint  { 

position  -2  2  -2 

orientation  -.1566  .9125  .3780  3.8643 

description  "Above  Astern  Port" 

} 

Viewpoint  { 

position  -2  2  0 

orientation   .3574  .8629  .3574  4.5654 

description  "Above  Stern" 
} 

Viewpoint  { 

position  -1.5  0  0 
orientation  0  1  0  -1.4 
description  "Close  Astern" 

} 

Viewpoint  { 

position  -2  0  1 
orientation  0  10  -.707 
description  "Close  Astern  Stbd" 

} 


Viewpoint  { 

position  -1.11  0  .5 

orientation  0  10  0 

description  "Close  Stbd  Stern' 
} 

Viewpoint  { 

position  -1.11  0  2 
orientation  0  10  0 
description  "Stbd  Stern" 

} 


Viewpoint  { 
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} 


position  0  -1.5  1.5 
orientation  10  0  .707 
description  "Below  Stbd  Beam" 


Navigationlnfo  { 

type  [  "EXAMINE1 
} 


" ALL "  ] 


Group  { 
children 


#  DEF  AUV 


#  Fwd  Top  Plane 
Transf orm{ 

translation  .6223  .13335  0 

children! 

#A  Plane  Shape 
DEF  A_Plane  Shape { 

appearance  Appearance { 

material  Material  {dif fuseColor 
}  tend  Appearance 
geometry  IndexedFaceSet  { 
coord  Coordinate { 


2  0} 


point[  .0635, 

0, 

-.0127, 

#0 

.0381, 

.1778, 

-.0127, 

#1 

-.0381, 

.1778, 

-.0127, 

#2 

-.0889, 

0, 

-.0127, 

#3 

.0635, 

0, 

.0127, 

#4 

.0381, 

.1778, 

.0127, 

#5 

-.0381, 

.1778, 

.0127, 

#6 

-.0889, 

0, 

.0127 

#7 

]  #end  Points 

}  #end  Coordinates 

coordlndexf  0,  3, 

2, 

1, 

-1, 

4,  5, 

6, 

7, 

-1, 

0,  1, 

5, 

4, 

-1, 

1,  2, 

6, 

5, 

-1, 

2,  3, 

7, 

6, 

-1, 

0,  3, 

7, 

4, 

-1 

]  #end  coordlndex 

creaseAngle  3.14159 

}  #end  IndexedFaceSet 

}  #end  Shape 

]  #end  Transform  children 

}  #end  Transform 

#  Aft  Top  Plane 
Transform{ 

translation  -.7747  .13335  0 

children [ 
USE  A_Plane 

]#  end  Transform  children 
}#end  Transform 

#Fwd  Bottom  Plane 
Trans form { 

rotation  10  0  3.14159267 

translation  .6223  -.13335  0 

children [ 
USE  A_Plane 

] #end  Transform  children 
}#end  Transform 
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#Aft  Bottom  Plane 
Transform! 

rotation  10  0  3.14159267 

translation  -.7747  -.13335  0 

children[ 

USE  A_Plane 

]  #end  Transform  children 
}#end  Transform 

#Stbd  Fwd  Plane 
Trans form{ 

rotation  10  0  1.5708 

translation  .6223  0  .20955 

children [ 
USE  A_Plane 

] #end  Transform  children 
}#end  Transform 

#Stbd  Aft  Plane 
Transform{ 

rotation  10  0  1.5708 

translation  -.7747  0  .20955 

children [ 
USE  A_Plane 

] #end  Transform  children 
}#end  Transform 

#Port  Fwd  Plane 
Transform! 

rotation  10  0  -1.5708 

translation  .6223  0  -.20955 

children [ 
USE  A_Plane 

] #end  Transform  children 
}#end  Transform 

#Port  Aft  Plane 
Transform! 

rotation  10  0  -1.5708 

translation  -.7747  0  -.20955 

children [ 
USE  A_Plane 

] tend  Transform  children 
}#end  Transform 

#Fwd  Vert  Thruster 
Transform! 

translation  .3302  0  0 
children! 
Shape! 

appearance  Appearance! 

material  Material  !dif fuseColor  .2  .2  .2} 
} 

geometry  Cylinder  !height  .29  radius  .0635}  #  !height  .2737  radius  .0635} 
} #end  Shape 
] #end  Children 
}#end  Transform 

#Aft  Vert  Thruster 
Transform! 

translation  -.4953  0  0 
children! 
Shape! 

appearance  Appearance! 

material  Material  !dif fuseColor  .2  .2  .2} 
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} 

geometry  Cylinder  {height  .29  radius  .0635}  #  {height  .2737  radius  .0635} 
}#end  Shape 
] #end  Children 
}#end  Transform 

#Fwd  Horiz  Thruster 
Transformf 

rotation  10  0  1.5708 
translation  .4699  0  0 
children [ 
Shape { 

appearance  Appearance { 

material  Material  {dif fuseColor  .2  .2  .2} 
} 

geometry  Cylinder  {height  .44  radius  .0635}  #  {height  .4231  radius  .0635} 
} #end  Shape 
] #end  Children 
}#end  Transform 

#Aft  Horiz  Thruster 
Trans form { 

rotation  10  0  1.5708 
translation  -.6223  0  0 
children [ 
Shape { 

appearance  Appearance { 

material  Material  {dif fuseColor  .2  .2  .2} 
} 

geometry  Cylinder  {height  .44  radius  .0635}  #  {height  .4231  radius  .0635} 
}  #end  Shape 
]  #end  Children 
}  #end  Transform 

#Hull 
Group { 

children [ 

#Bow  Cowling 
Shape { 

appearance  Appearance { 

material  Material  {dif fuseColor   0  0  .8} 

}  #end  Appearance 

geometry  IndexedFaceSet  { 
coord  Coordinate { 

point[  .6985,   .13335,  -.20955,  #0  Start  of  Bow  Cowling 

.6985,   .13335,  .20955,  #1 

.6985,  -.13335,  .20955,  #2 

.6985,  -.13335,  -.20955,  #3 

1.05,  .085,  0,  #4 

1.05,  0,  .1143,  #5 

1.05,  -.085,  0,  #6 

1.05,  0,  -.1143,  #7 

1.05,  .04572,  -.098985,  #8 

1.05,  .079188,  -.05715,  #9 

1.05,  .079188,   .05715,  #10 

1.05,  .04572,    .098985,  #11 

1.05,  -.04572,  .098985,  #12 
1.05,  -.079188,  .05715,  #13 
1.05,  -.079188,  -.05715,    #14 
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1.05,  -.04572, 


.098985,   #15 


1 

1, 

.04064, 

.02032, 

#16 

1 

1, 

.02032, 

.06096, 

#17 

1 

1, 

-.02032, 

.06096, 

#18 

1 

1, 

-.04064, 

.02032, 

#19 

1 

1, 

-.04064, 

-.02032, 

#20 

1 

1, 

-.02032, 

-.06096, 

#21 

1 

1, 

.02032, 

-.06096, 

#22 

1 

1, 

.04064, 

-.02032, 

#23 

1.11, 


0, 


0, 


#24 


.6985, 

.13335, 

.20955, 

#25  Start  of  Stern  Cowling 

.6985, 

.13335, 

-.20955, 

#26 

.6985, 

-.13335, 

-.20955, 

#27 

.6985, 

-.13335, 

.20955, 

#28 

1.1303, 

0, 

.20955, 

#29 

1.1303, 

0, 

-.20955, 

#30 

6985, 

.13335, 

.0635, 

#31  Start  of  Rudder  Post 

8509, 

.13335, 

.0635, 

#32 

8509, 

.13335, 

-.0635, 

#33 

6985, 

.13335, 

-.0635, 

#34 

6985, 

-.13335, 

.0635, 

#35 

8509, 

-.13335, 

.0635, 

#36 

8509, 

-.13335, 

-.0635, 

#37 

6985, 

-.13335, 

-.0635, 

#38 

]  #end  Points 
}  #end  Coordinates 


coordIndex[  0 
1 

2 
0 


9 
9 

4 
4 
10 
10 
11 
11 

5 

5 

12 

12 

13 


26,  34,  33,  32,  31,  25,  1,  -1,  #Hull 

25,  29,  28,  2,  -1, 

28,  35,  36,  37,  38,  27,  3,  -1, 

3,  27,  30,  26,  -1, 


4, 
1, 
5, 
2, 
6, 
3, 
7, 


0,  7, 


0, 
9, 
0, 
4, 

1, 
10, 

1, 
11, 

1, 

5, 

2, 
12, 

2, 
13, 

2, 


-1, 
-1, 
-1, 
-1, 
-1, 
-1, 
-1, 
-1, 

-1, 
-1, 
-1, 
-1, 
-1, 
-1, 


10, 

1, 
11, 
1, 
5, 
1, 

12, 
2, 

13, 
2, 
6, 


#Bow  Cowling 


-1, 
■1, 
■1, 
■1, 
■1, 
■1, 

-1, 
-1, 

•1, 

•1, 

-1, 
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13, 


2, 


■1, 


6, 

3, 

14, 

-1, 

6, 

14, 

3, 

-1, 

14, 

3, 

15, 

-1, 

14, 

15, 

3, 

-1, 

15, 

3, 

7, 

-1 

15, 

7, 

3, 

-1, 

4, 

10, 

16, 

-1, 

10, 

11, 

16, 

-1, 

11, 

5, 

17, 

-1, 

5, 

12, 

18, 

-1, 

12, 

13, 

19, 

-1, 

13, 

6, 

19, 

-1, 

6, 

14, 

20, 

-1, 

14, 

15, 

20, 

-1, 

15, 

7, 

21, 

-1, 

7, 

8,  22, 

1, 

8, 

9,  23,  - 

1, 

9, 

4,  23,  - 

1, 

4, 

16, 

23, 

-1, 

11, 

17, 

16, 

-1, 

5, 

18, 

17, 

-1, 

12, 

19, 

18, 

-1, 

6, 

20, 

19, 

-1, 

20, 

15, 

,  21, 

-1, 

21, 

7, 

22, 

-1, 

22, 

8, 

23, 

-1, 

23, 

16 

,  24, 

-1, 

16, 

17 

,  24, 

-1, 

17, 

18 

,  24, 

-1, 

18, 

19 

,  24, 

-1, 

19, 

20 

,  24, 

-1, 

20, 

21 

,  24, 

-1, 

21, 

,  22 

,  24, 

-1, 

22, 

,  23 

,  24, 

-1, 

26, 

,  27 

,  30, 

-1, 

25, 

,  26 

,  30, 

29,  -1, 

25, 

,  29 

,  28, 

-1, 

27 

,  28 

,  29, 

30,  -1, 

31 

,  32 

,  36, 

35,  -1, 

32 

,  33 

,  37, 

-  36,  -1, 

34 

,  38 

,  37, 

,  33,  -1, 

#Start  of  Stern  Cowling 


]  tend  coordlndex 
creaseAngle  3.14159 

}  tend  IndexedFaceSet 
}  tend  Shape 

]  tend  Hull  Group  Children 
}  tend  Hull  Group 

tThe  Stbd  screw 
Transform! 

translation  -1.1557  0  .09525 
children[ 

Group {  t  DEF  Stbd_Screw 

children [ 
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DEF  Stbd_Blade  Group { 
children! 
Trans form{ 

rotation  0  1  0  -.39 
children [ 
Shape { 

appearance  Appearance { 

material  Material  {dif fuseColor   .226  .197  0} 
}  tend  Appearance 

geometry  IndexedFaceSet  { 


iord  Coordinate  { 

point[  0, 

0, 

-.00508, 

#0 

0, 

.02540, 

-.02032, 

#1 

0, 

.04572, 

-.01524, 

#2 

0, 

.05080, 

-.00508, 

#3 

0, 

.05080, 

.00508, 

#4 

0, 

.04572, 

.01524, 

#5 

0, 

.02540, 

.02032, 

#6 

0, 

0, 

.00508 

#7 

]  #end  Points 
}  tend  Coordinates 

coordlndexf  0,  1,  2,  3,  4,  5,  6,  7,  -1, 
0,  7,  6,  5,  4,  3,  2,  1,  -1 
]  #end  coordlndex 
}  #end  IndexedFaceSet 
}  #end  A_Blade  Shape 
] #end  transform  children 
}  #end  transform 
]  #end  group  children 
}  #end  A_Blade  Group 

Trans form { 

rotation  10  0  1.5708 

children!  USE  Stbd_Blade  ] 
}  tend  Transform 

Transform! 
rotation  10  0  3.14159267 
children!  USE  Stbd_Blade  ] 
}  #end  Transform 

Transform! 

rotation  10  0  -1.5708 

children!  USE  Stbd_Blade  ] 
}  #end  Transform 

#The  shaft 
Transform! 

rotation  0  0  1  1.5708 
translation  .0281  0  0 
children [ 
Shape  { 

appearance  Appearance { 

material  Material  {dif fuseColor   .226  .197  0} 
}  #end  Appearance 

geometry  Cylinder  {radius  .008  height  .0762} 
}  #end  Shape 
]  #end  children 
}  #end  Transform 

#The  shaft  end  cap 
Trans form { 

rotation  0  0  1  1.5708 
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translation  -.015  0  0 
children [ 
Shape  { 

appearance  Appearance { 

material  Material  {dif fuseColor   .226  .197  0} 
}  #end  Appearance 

geometry  Cone  {bottomRadius  .008  height  .01) 
}  tend  Shape 
]  tend  children 
}  tend  Transform 
]  tend  Screw  Group  Children 
}  tend  Screw  Group 
]  tend  Transform  Children 
}  tend  Transform 

tThe  Port  screw 
Trans form { 

translation  -1.1557  0  -.09525 
children [ 

Group {  t  DEF  Port_Screw 

children [ 

DEF  Port_Blade  Group { 
children [ 
Transform! 

rotation  0  10  .39 
children [ 
Shape { 

appearance  Appearance { 

material  Material  {dif fuseColor   .226  .197  0} 
}  tend  Appearance 

geometry  IndexedFaceSet  { 
coord  Coordinate! 


point [    0, 

0, 

-.00508, 

to 

0, 

.02540, 

-.02032, 

tl 

0, 

.04572, 

-.01524, 

#2 

0, 

.05080, 

-.00508, 

#3 

0, 

.05080, 

.00508, 

#4 

0, 

.04572, 

.01524, 

#5 

0, 

.02540, 

.02032, 

#6 

0, 

0, 

.00508 

t7 

]    tend  Points 

tend  Coordinates 

iord!ndex[ 

0,    1,    2, 

3,    4,     5, 

6, 

7, 

-1 

0,    7,    6, 

5,    4,    3, 

2, 

1, 

-1 

]  tend  coordlndex 
}  tend  IndexedFaceSet 
}  tend  A_Blade  Shape 
] tend  transform  children 
}  tend  transform 
]  tend  group  children 
}  tend  A_Blade  Group 

Transform! 

rotation  10  0  1.5708 
children!  USE  Port_Blade  ] 

}  tend  Transform 

Transform! 
rotation  10  0  3.14159267 
children!  USE  Port_Blade  ] 
}  tend  Transform 
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Transform{ 

rotation  10  0  -1.5708 

children!  USE  Port_Blade  ] 
}  #end  Transform 

#The  shaft 
Transform! 

rotation  0  0  1  1.5708 
translation  .0281  0  0 
children! 
Shape  { 

appearance  Appearance! 

material  Material  {dif fuseColor   .226  .197  0} 
}  #end  Appearance 

geometry  Cylinder  !radius  .008  height  .0762} 
}  tend  Shape 
]  #end  children 
}  #end  Transform 

#The  shaft  end  cap 
Transform! 

rotation  0  0  1  1.5708 
translation  -.015  0  0 
children! 
Shape  ! 

appearance  Appearance! 

material  Material  {dif fuseColor   .226  .197  0} 
}  #end  Appearance 

geometry  Cone  {bottomRadius  .008  height  .01} 
}  #end  Shape 
]  #end  children 
}  #end  Transform 
]  #end  Screw  Group  Children 
}  #end  Screw  Group 
]  #end  Transform  Children 
}  #end  Transform 

] #end  AUV  Group  children 

}  #end  AUV  Group 

#end  auv.wrl 
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APPENDIX  C.  EXPERIMENTAL  SCRIPTS  AND  RESULT  DATA 


1.  Mission.script.SeaStateTest 

#  your  mission  is 

#  Sea  State  Test 


#  mission. script . SeaStateTest 
ff  i  i  i  i 

#  initial  position 
position     -180  50   2 


#  drive  straight  into  seas 
course  000 

depth   2 
rpm     3  50 

#run  test  for  5  minutes 
wait    300 

#done,  stop 
rpm  0 
wait  60 

#  test  complete 
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2.        Mission.scriptFlowFieldTestLoop 

#  your  mission  is 

#  flow  field  test  loop 

#  mission . script . FlowFieldTestLoop 
"  i  i  i  i 

#  shift  DS3  0  Precision  Doppler  Sonar  mode 

#  to  track  speed  through  water,  not  speed  over  ground 

"  i  i  i  i 

#  hull  is  at  y  distance  of  83  feet 

TT    i     i     i     i 

#  initial  position  inside  hull 
position     117  88   43 
orientation    0   0  335 

standoff -distance  2.0 

#  launch  from  lower  port  torpedo  tube 
hover  122  85.5  43  335 

wait    10 

#  drive  out  of  tube 
rpm   700 

wait   20 

#  go  to  surface  and  turn  south 
depth    2 

course  180 
wait    90 

#  operate  at  surface  first,  then  go  deep 
rpm     0 

wait   60 

thrusters-on 
rpm   7  00 
depth  7  0 
wait   60 

#  drive  to  aft  end  of  submarine 
standoff -distance  4.0 

hover  -130  75  33  000 
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#  steer  collision  avoidance  sonar 

#  to  track  the  submarine  hull 
SONAR_725  090  30  1 

#  wider  scan  for  tracking  sonar 
SCAN-WIDTH  45 

wait  10 
hover-off 

#  take  position  just  aft  of  the  pump  discharge 
rpm     40  0 

course  000 
depth  33 
wait     60 

#  stabilize  after  pump  discharge 
waypoint  -25  76  33 

#  drive  through  pump  suction 
course  000 

rpm  400 
depth  3  3 
wait      5 

#  stabilize  after  pump  suction 
waypoint  90  80  33 

#  dock  with  torpedo  upper  port  tube, 

#  then  hover  with  nose  in  tube 

standoff -distance  0.5 

course   025 

hover     108.5  84  33 

#  move  in 

hover     117    88  33 


#  stabilize  for  next  iteration 

wait  10 

hover-off 


#  docking  complete 
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3.    SEA  STATE  1  SIMULATION  DATA 
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4.        SEA  STATE  2  SIMULATION  DATA 
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5.        SEA  STATE  3  SIMULATION  DATA 
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6.         SEA  STATE  4  SIMULATION  DATA 
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7.         SEA  STATE  5  SIMULATION  DATA 
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8.        X  VERSUS  Y  FOR  NO-FLOW  SIMULATION 
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9.        X  VERSUS  Y  FOR  NORMAL  FLOW  SIMULATION 
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10.      X  VERSUS  Y  FOR  EXTREME  FLOW  RUN 
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APPENDIX  D.  FLOW  GENERATION  CODE 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  n  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
i* 

Program:  FlowFieldGenerator .C 

Description:       This  program  creates  the  data  required  for  a  complex  flow  field 
associated  with  a  submarine  driving  through  the  water.  It  uses 
Flat  Plate  Fluid  Flow  theory  to  create  a  series  of  files  which 
contain  the  data  used  by  the  Phoenix  AUVs  Virtual  environment . 

This  program  is  based  upon  a  program  which  was  written  in  fortran 
called   ITBL  (Incompressible  Turbulent  Boundary  Layer)  from  a 
mechanical  Engineering  text.  The  book  was  called  Boundary  Layer 
Analysis,  by  Joseph  A.  Schetz . 


Revised: 
System: 
Compiler : 
Compilation: 


26  January  98 

Irix  5.3 

ANSI  C++ 

irix>  make  FlowFieldGenerator .o 

irix>  CC  FlowFieldGenerator .C  -lm  -c  -g  +w 

-c  ==  Produce  binaries  only,  suppressing  the  link  phase. 
+w  ==  Warn  about  all  questionable  constructs. 


Author: 
Thesis : 

Advisors : 
References 

Notes : 


Kevin  Byrne 

Byrne,  Kevin  M. ,  Real-Time  Modeling  of  Cross -Body 
Flow  for  Torpedo  Tube  Recovery  of  the  Phoenix  Autonomous 
Underwater  Vehicle,  Masters  Thesis,  Naval  Postgraduate 
School,  Monterey  California,  March  1998. 

Dr.  Don  Brutzman,  Dr.  Bob  McGhee 

Schetz,  Joseph  A.,  _Boundary  Layer  Analysis_, 

Prentice  Hall,  Englewood  Cliffs,  NJ,  1992. 


// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 


2-d  Boundary  Layer  Computation,   Incompressible, 
Turbulent,  1st  Order,   Implicit 

Mixing-length  or  Eddy-viscosity  Model  or  Tke  Model. 

Equations  Are  Dimensionless  Using  Freestream  Velocity, 
Uinf,  Viscosity,  Muinf,  and  Density,  Rhoinf,  and  a 
Reference  Length,  L;  X/l,  Y/l,  U/uinf,  Also 
Re  =  Rhoinf *uinf*l/muinf 
Pick  L  =  1.0. 

Other  Variables : 

Rkap,  Kappa  in  the  Mean  Flow  Turbulence  Models 

Ypa,  Y  Sub  A+ 

Del,  Starting  Boundary  Layer  Thickness 

Duedx,  Derivative  of  Edge  Velocity  in  the  X  Direction 

Red,  Reynolds  Number  Based  on  Delta 

Usue,  Ustar/uedge 

A,b,c,  Splitting  up  the  Boundary  Layer  Equations 
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Sample  Problem  of  a  Flat  Plate  with  Uinf  =  10.0 
X  =  5.0.  Goto  X  =  6.0.  Take  Nu (=muinf /rhoinf )  = 


Start  at 
1.0e-5.  Rex=5.0e6 


// 

// 

// 

//      Use  Simple  Integral  Solution  to  Get  Initial  Values. 

//       Delta  =  0.0856.  Cf  =  0.002665.  Other  Flows  Can  Be  Set  by  User. 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


♦include  <iostream.h> 
♦include  <iomanip.h> 
♦include  <fstream.h> 
♦include  <math.h> 

♦define  TRUE   1 
♦define  FALSE  0 

struct  FlowGridElements 

double  direction; 

double  x_magnitude; 

double  y_magnitude; 

double  z_magnitude; 
}; 


//direction   relative  to  sub  heading 
//The  magnitudes  are  dimensionless 
//forces  in  the  submarine  reference  frame 


const  int  FLOWFIELDLENGTH  =  721; 
const  int  FLOWFIELDWIDTH   =  61; 


1 12 
//4 


lenght  of  sub  om  .5  ft  inc 

the  number  of  cross  sections  on  AUV 


//These  grids  are  used  to  pass  the  initial  flow  profile  from  the  flat 
//Plate  model  to  the  tube  level  model.  The  tube  level  model  refines 
//these  arraysin  the  areas  of  interest. 

FlowGridElements  global lktgr id [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]  =  {0} 
FlowGridElements  global2ktgrid [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]  =  {0} 
FlowGridElements  global3ktgrid [FLOWFIELDLENGTH] [FLOWFIELDWIDTH]  =  {0} 


//Local  Constants 

const  double  RKAP  =  0.41; 

const  double  YPA  =  9.7; 

// 

void  eddy(  int  NNX,  int  MMAX,  int  MEST,  const  double  RE,  double  DY, 

double   U0 [ ] ,   double  UE [ ] ,  double  T [ ]  ,  double  CF [ ] ) 


double  RMUT   =  0.0 

double  Y     =0.0 

double  YP    =0.0 

double  DELST  =0.0 


for  (int  ie  =  2;  ie  <=  MEST;  ie++)   { 

DELST  =  DELST  +  DY* ( 1 . 0-0 . 5* (U0 [ ie-1 ] +U0 [ ie] ) /UE [NNX] ) 
} 


//    CLAUSER  EDDY  VISCOSITY  MODEL 
RMUT  =  0.018*RE*UE[NNX] *DELST; 

for  (int  ig  =  1;  ig  <=  MMAX;  ig++)   { 

Y   =  (ig-1)  *  DY; 

YP  =  Y*UE[NNX] *RE*sqrt(0.5*CF[NNX-l] ) ; 

//REICHART  MODEL  FOR  COMPLETE  INNER  REGION 
T[ig]  =  RKAP* (YP-YPA*tanh(YP/YPA) ) ; 
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if  (T[ig]  >  RMUT)   { 

T[ig]  =  RMUT; 
} 
} 

return; 

}    //end  of  function  eddy 


// 

void  TRID  (  int  MM,  double  A[],  double  B[],  double  C[],  double  R[],  double  S[])  { 

double  GAM [550] ; 
double  RP[550] ; 
double  DENO; 

//  THOMAS  ALGORITHM 
GAM [1]  =  C [ 1 ]  /  B [ 1 ]  ; 
RP  [  1  ]  =  R  [  1  ]  /  B  [  1  ]  ; 

for  (int  ih  =  2;  ih  <=  MM;  ih++)   { 

DENO  =  B[ih]  -  A[ih]  *  GAM[ih-l]; 
GAM[ih]  =  C[ih]  /  DENO; 

RP[ih]  =  (R[ih] -A[ih] *RP[ih-l] )  /  DENO; 
} 

S[MM]  =  RP[MM] ; 

for  (int  ii  =  1;  ii  <=  MM-1;  ii++)   { 

S[MM-ii]  =  RP[MM-ii]-GAM[MM-ii] *S[MM-ii+l] ; 

} 

return; 

}    //end  of  function  TRID 


// 

void  f latPlateFlowFieldGenerator  (  void  )  { 

//  YOU  MUST  GIVE  INITIAL  X  (XI),  FINAL  X  (XF) ,  (CNU) ,  (UNINF) , 

//  (NMAX) ,  (MMAX)  AND  (DY) 

//  PICK  MMAX  BASED  ON  INITIAL  BOUNDARY  LAYER  THICKNESS  AND 

//  NUMBER  OF  POINTS  ACROSS  THE  LAYER.   USE  AT  LEAST  400  ACROSS 

//  DELTA.   ADD  AT  LEAST  100  POINTS  ABOVE  DELTA. 

// 

//  PICK  NMAX  BASED  ON  LENGTH  OF  REGION  AND  DX  DESIRED.   DX 

//  CAN  BE  OF  THE  ORDER  OF  INITIAL  DELTA/FIVE.  TAKE  L  =  1.0. 

//Constant  Variables 

const  int  ARRAY_SIZE  =  550; 

const  double    XI  =  0.0;  //Initial  X  position  where  flow  hits  plate 

const  double     CNU  =  0.000001; 

// 

//Variables  I  needed  to  add  for  iteration  down  sub  Hull 

int  current_distance      =  0 ; 
int  index_dif ference       =  0; 
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//Length  in  meters  =  360  ft,  truly  109.7m 


double  submarine_length_meters  =  111; 
//double  submarine_speed   =  1.0; 

struct  flowRecord  { 

double  x_magnitude; 

double  y_magnitude; 

double  z_magnitude; 

double  direction; 
}; 


flowRecord  nontubelevelgrid[FLOWFIELDLENGTH] [FLOWFIELDWIDTH] ; 


//Array  declararations 
double  U[ARRAY_SIZE] ; 
double  U0[ARRAY_SIZE] ; 
double  V[ARRAY_SIZE] ; 
double  V0[ARRAY_SIZE] ; 
double  CF[150] ; 
double  A[ARRAY_SIZE] 
double  B[ARRAY_SIZE] 
double  C[ARRAY_SIZE] 
double  R[ARRAY_SIZE] 
double  TKEO[ARRAY_SIZE] ; 
double  TMU[ARRAY_SIZE] ; 
double  UE[150] ; 
double  DUEDX[150]; 
double  Y[ARRAY_SIZE] ; 

//Varibles  Required  For  Fluid  Caluations 


//distance  from  hull  feet 


int 
int 
int 
int 
int 
int 
int 

double 
double 

value. 035) 
double 
double 
double 
double 
double 

discharge 
double 
double 
double 

double 
(ft) 

double 
(ft) 


MMAX  =  60; 

NMAX  =  15; 

MEST  =  401; 

FM1  =  MEST-1; 

NMAXP  =  NMAX; 

MMAXP  =  MEST+100; 
NNX; 


//MMAX  originally  was  525,  NMAX  originally  was  101 
//This  is  the  M  index  for  the  initial  Delta 


XF 
DY 


0.0; 

0. 02 /MMAX; 


DX; 

DENO  ; 

DEL  =  0.00015; 

Y0D; 

pump_out let_jet_f actor ; 


//The  position  at  which  the  profile  is  generated 

//  step  distance  away  from  hull  per  calcualtion(last 

//  distance  from  the  start  of  plate 


//Holds  value  for  pump  force  reduction  sw 


pump_inlet_j et_f actor ;        //Holds  value  for  pump  force  reductionsw  suction 
pump_outlet_jet_speed  =  2.5;  //Holds  value  for  pump  force  (knots) 
pump_inlet_jet_speed   =  1.0;  //Holds  value  for  pump  force  (knots) 

pumpSuctionPosition_f t    =  180.5;  //The  position  along  hte  hull  of  suction 

pumpDischargePosition_f t  =  245.5;  //The  position  along  hte  hull  of  discharge 


double     suctionBegin_m 
suction  forces (m) 

double     suctionEnd_m 
forces (m) 

double    dischargeBegin_m 
discharge  f orces (m) 

double    dischargeEnd_m 
discharge  f orces (m) 


=  (pumpSuctionPosition_f t  -  6.5)  *  0.3048;  //Begin  of 

-  (pumpSuctionPosition_f t  +6.5)  *  0.3048;  //End  of  suction 

=  (pumpDischargePosition_ft  -  6.5)  *  0.3048;  //Begin  of 

=  (pumpDischargePosition_f t  +6.5)  *  0.3048;  //End  of 
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// 

//Output  streams  to  hold  the  generated  flow  fields  for  later  usage 

f latplatef lowf ieldlkt .data  -  Holds  the  entire  flatplate  model  flow  field 

for  a  submarine  speed  of  1  kt . 
f latplatef lowf ield2kt. data  -  Holds  the  entire  flatplate  model  flow  field 

for  a  submarine  speed  of  2  kt . 
f latplatef lowf ield3kt .data  -  Holds  the  entire  flatplate  model  flow  field 

for  a  submarine  speed  of  3  kt . 


// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 


These  others  are  just  for  data  verification. 

f latprof i^ 

f latslicef 

f latslice] 

flatslice] 

f latslice^ 

flatslice250 .data  -  Holds  flat  plate  data  for  slice  at  250  ft 


.le.data   -  Holds  flat  plate  data  for  sub  profile 
?50.data   -  Holds  flat  plate  data  for  slice  at  50  ft 
:100.data  -  Holds  flat  plate  data  for  slice  at  100  ft 
:150.data  -  Holds  flat  plate  data  for  slice  at  150  ft 
:200.data  -  Holds  flat  plate  data  for  slice  at  200  ft 


ofstream  platelktOutput  (" f latplatef lowf ieldlkt .data" ,  ios::out); 
ofstream  plate2ktOutput  (" f latplatef lowf ield2kt .data" ,  ios::out); 
ofstream  plate3ktOutput  (" f latplatef lowf ield3kt .data" ,  ios::out); 
ofstream  plateProf ileOutput  ( " f latprof ile.data" ,  ios::out); 
ofstream  plateSlice50Output  ( " f latslice50 .data" ,  ios::out); 
ofstream  plateSlicelOOOutput ( " f latslicelOO .data" ,  ios::out); 
ofstream  plateSlicel50Output ( " f latslicel50 .data" ,  ios::out); 
ofstream  plateSlice200Output ( " f latslice200 .data" ,  ios::out); 
ofstream  plateSlice250Output ( " f latslice250 .data" ,  ios::out); 

for  ( int  submarine_speed  =  1;  submarine_speed  <  4;  submarine_speed++)  { 

int  las t_distance_fi lied  =  0; 

double    UINF  =  (double) submarine_speed;  //This  is  the  flow  strength  in  open  water 

//This   declared   here  due  to  dependence  on  other  variables 

double    RE  =  UINF  *  submarine_length_meters  /  CNU; 

// 

//Initialize  flow  field  to  zero  prior  to  each  speed  iteration 
for  (  int  row  =  0;  row  <  FLOWFIELDLENGTH;  row++)  { 
for  (int  col  =  1;  col  <  FLOWFIELDWIDTH;  col++)  { 


nontubelevelgrid[row] [col] .x_magnitude  =  0.0 

nontubelevelgrid[row] [col] .y_magnitude  =  0.0 

nontubelevelgrid[row] [col] . z_magnitude  =  0.0 

nontubelevelgrid[row] [col] .direction  =  180.0 


//- 


//This  is  the  main  loop.  It  generates  the  Flow  field  from  bow  to  stern 
//in  1  meter  increments.  Each  profile  starts  from  the  hull  and 
//goes  outward  until  flow  force  =  Uinf  (-30  ft) 

for  (int  generationloop  =  1;  generationloop  <  submarine_length_meters   ; 
generationloop++)  { 

//Flag  for  file  output 
//  firstEntry  =  1; 

//This  increments  XF  by  1  m  each  time.  The  loop  will  run  from  bow  to  stern 

XF  =  (double) generationloop ; 

DX  =  (XF-XI)  /  (NMAX-1); 

//initialize  UE  and  DUEDX  arrays  they  are  only  150  elements  large 
for  (  int  iw  =  0;  iw  <=  NMAX;  iw++)  { 
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UE[iw]     =1.0; 
DUEDX[iw]  =  0.0; 
} 

//additional  variable  which  depend  on  nitialized  arrays 

CF[1]  =  0.001; 

double  USUE  =  sqrt (CF [1] /2 . 0) ; 

double  RED  =  RE  *  DEL  *  USUE  *  UE [ 1 ] ; 

//initialize  other  arrays,  these  are  550  elements  large 
for  (  int  ix  =  1;  ix  <=  MMAX;  ix++)  { 

U[ix]  =  UE[1] ; 

U0[ix]  =  UE[1] ; 

V[ix]  =  0.0 

V0[ix]  =0.0 

TKEO[ix]  =0.0 

TMU[ix]  =0.0 


//         NO  SLIP  CONDITION 
U[l]  =  0.0; 
U0[1]  =  0.0; 

// 

//The  initial  profiles  of  U  and  V  can  be  changed  by  the  user. 

//MEST  is  the  M  index  for  the  initial  Delta. 

//Assume  a  Coles  Wake  Law  Initial  Velocity  Profile 

// 

for  (int  iy  =  2;  iy  <=  MEST;  iy++)  { 

Y0D  =  (double) (iy-1)  /  (double) FM1; 
U0[iy]  =  USUE*UE[1] * 

(1.0/RKAP*log(Y0D*RED)  +  4.90  +  0.51/RKAP 
*  2.0  *  pow( (sin(Y0D*1.5708) )  ,2)); 
V0[iy]  =  0.0; 
} 

//By  this  point  all  initialization  is  done,  U0  and  V0  are  initial  U+V  profiles 
int   done_200  =  FALSE; 
int  iz  =  2; 

while  ( (  iz  <=  NMAX  )  &&  (done_200  ==  FALSE) )  { 

NNX  =  iz; 

U0[MMAX]  =  UE[iz] ; 

V0[MMAX]  =  0.0; 

eddy(NNX,  MMAX,  MEST,  RE,  DY,  U0 ,  UE ,   TMU,  CF)  ; 

B[l]  =  1.0; 
C[l]  =  0.0, 
R[l]  =  0.0; 
A[MMAX]  =  0.0; 
B[MMAX]  =  1.0; 
C[MMAX]  =  0.0; 
R[MMAX]  =  UE[iz] ; 
DENO  =  RE*DY*DY; 

for  (int  ia  =  2;  ia  <=  MMAX-1;  ia++)  { 

A[ia]  =  -0.5*V0 [ia] /DY- (1 . 0+TMU [ia-1] ) /DENO; 
B[ia]  =  U0[ia] /DX+ ( 2. 0+TMU [ia-1] +TMU[ia] ) /DENO; 
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C[ia]  =  0.5*V0[ia] /DY-(1.0+TMU[ia] ) /DENO; 
R[ia]  =  UE[iz] *DUEDX [ iz] +U0 [ ia] *U0[ia] /DX; 

} 

TRID(MMAX,  A,  B,  C,  R,  U); 

for  (int  ib  =  2;  ib  <=  MMAX  -  1;  ib++)  { 

V[ib]  =  V[ib-1] -(0.5*DY/DX) * (U [ ib] -U0 [ ib] +U[ib-1] -U0 [ib-1] ) ; 
} 

int  done  =  FALSE; 
int  ic  =  MEST  -  10; 

while  ((ic  <=  MMAX)  &&  (done  -=   FALSE))   { 
if  (U[ic]  >  0.99*UE[iz] )  { 
MEST  =  ic; 
MMAXP  =  MEST+100; 
done  =  TRUE; 
} 

ic  +  +; 
} 

//This  steps  in  the  X-direction  from  front  of  plate  to  current  position 
for  (int  id  =  2;  id  <=  MMAX;  id++)   { 

U0[id]  =  U[id] ; 
V0[id]  =  V[id] ; 
} 

CF[iz]  =  (4.0*U0[2]-U0[3] ) / (pow(UE[iz] ,2) *DY*RE) ; 

//Check  if  near  Seperation,  if  so  this  profile  is  done 
if  (CF[iz]  <  0.0001)  { 

NMAXP  =  iz; 
done_200  =  TRUE; 
} 

iz  +  +; 
}  //end  of  for  200  loop 

if  (MMAXP  >  MMAX)  { 

MMAXP  =  MMAX; 
} 

// 

//This  section  puts  data  in  seperate  files  for  later  use. 
//The  data  is  formatted  in  the  following  order: 
//     X-dir  flow  component  Y-dir  Z-dir  vector  direction 
//All  values  are  unitless.  This  allows  scaling  during  usage. 
// 

//Calculate  the  number  of  feet  down  the  hull  we  are 
current_distance  =  (int) (generationloop/ . 3048)  *  2; 

//Check  to  ensure  we  have  a  good  ft  increment  on  hull 
if  (current_distance  >  720  )  { 

cout  <<  "  Distance  along  hull  exceeded  360  ft,  reset  to  360  ft  (720)"  <<  endl ; 

current_distance  =  720; 
} 

if  (current_distance  <  0  )  { 

cout  <<  "  Distance  along  hull  below  0  ft,  reset  to  1"  <<  endl; 
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current_di stance  =  0; 
} 

//Calculate  the  number  of  rows  to  be  filled. This  is  needed  because  the 
//dynamics  model  needs  a  flow  field  with  0.5  ft  increments,  and  this 
//generates  a  field  of  1  meter  increments.  We  interpolate  to  fill 
//in  the  missing  data 
index_dif ference  =  current_distance  -  last_distance_f illed; 

//Output  routine  to  put  Values  in  proper  arrays  and  files 
//A  loop  is  used  to  access  each  U  value  for  this  position  on 
//Hull.  The  generationloop  index  represents  the  distance  along 
//  the  hull  in  meters 
for  (int  ij  =  0;  ij  <  MMAXP;  ij++)   { 

//Distance  from  the  hull  in  feet 

Y[ij]  =(ij-l)*DY*  submarine_length_meters  /  0.3048  ; 

// 

//This  section  does  array  output 

//output  of  flow  field  into  flowfield  arrays 

//We  must  fill  all  .5  ft  incremented  array  rows  between 

//current_distance  and   last_distance_f illed 

int  pass  =  1; 

for  (int  arrayindex  =  last_distance_f illed  +  1;  arrayindex  <  current_distance; 
arrayindex++)  { 

// 

//  The  output  data  is  given  in  knots  based  on  submarine  speed.  Dynamics 
converts  it  to  ft/sec 

//  To  convert  knots  to  ft/sec  kts*2000*3/60/60=  1.6667 

//In  order  to  get  this  force  into  true  x,  y,  z  components  it  is  necessary  to 
multiply  the  components 

//by  a  factor  which  relates  them  to  the  sub's  refernce  frame.  Since  for  the 
flat  plate  model 

//I  assume  x  and  z  components  are  zero,  only  Y  is  adjusted  .  For  the  tube 
level  profile  when 

//fully  integrated  each  component  will  need  to  be  adjusted. 

//reset  pump  jet  force  to  one 
pump_outlet_jet_f actor  =  1.0; 
pump_inlet_jet_f actor   =  -1.0; 


for  (int  column  =  0;  column  <  FLOWFIELDWIDTH;  column++)  { 

nontubelevelgrid [arrayindex] [column] .x_magnitude  =  0.0; 

nontubelevelgrid [arrayindex] [column] .y_magnitude  =  -  U[column]  * 
submarine_speed; 

nontubelevelgrid [arrayindex] [column] . z_magnitude  =  0.0; 

nontubelevelgrid [arrayindex] [column] .direction  =  180.0; 

//This  section  adds  a  pump  inlet  180  ft  back  on  the  hull.  It  starts  out  at 
full 

//force  and  diminishes  to  0  at  20  ft  out  from  the  hull.  It  assumes  water  is 
sucked  in  at  2.5  kts 

if  ( (generationloop  >  suctionBegin_m)  &&  (generationloop  <  suctionEnd_m) )  { 
nontubelevelgrid [arrayindex] [column] .x_magnitude  =  pump_inlet_jet_f actor 

*  pump_inlet_jet_speed; 

if    (pump_inlet_jet_f actor   <    -0.2)     { 

pump_inlet_jet_f actor   =   pump_inlet_jet_f actor   +    0.025; 
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} 

else  { 

pump_inlet_jet_f actor  =  0.0; 
} 


//This  section  adds  a  pump  discharge  jet  246  ft  back  on  the  hull.  It  starts 
out  at  full 

//force  and  diminishes  to  0  at  20  ft  out  from  the  hull. It  assumes  water  is 
discharged  in  at  2.5  kts 

else  if  ( (generationloop  >  dischargeBegin_m)  &&  (generationloop  < 
dischargeEnd_m) )  { 

nontubelevelgrid[arrayindex] [column] .x_magnitude  =  pump_outlet_jet_f actor 

*  pump_outlet_jet_speed; 

if  (pump_outlet_jet_factor  >  0.2)  { 

pump_outlet_jet_f actor  =  pump_outlet_jet_f actor  -  0.025; 
} 
else  { 

pump_outlet_jet_factor  =  0.0; 
} 


//Now  write  these  values  to  the  proper  file 
switch  ( (int) submarine_speed)  { 

case  1: 

platelktOutput  <<  arrayindex  <<  "  "  <<  column  <<  "  " 

<<  nontubelevelgrid [arrayindex] [column] .x_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] .y_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] . z_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] .direction 
<<  endl; 

//Update  the  global  array 

globallktgrid [arrayindex] [column] .x_magnitude  = 
nontubelevelgrid [arrayindex] [column] .x_magnitude; 

globallktgrid[arrayindex] [column] .y_magnitude  = 
nontubelevelgrid [arrayindex] [column] .y_magnitude; 

globallktgrid [arrayindex] [column] .z_magnitude  = 
nontubelevelgrid [arrayindex] [column] . z_magnitude; 

globallktgrid [arrayindex] [column] .direction    = 
nontubelevelgrid [arrayindex] [column] .direction; 

break; 
case  2 : 

plate2ktOutput  <<  arrayindex  <<  "  "  <<  column  <<  "  " 

<<  nontubelevelgrid [arrayindex] [column] .x_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] .y_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] . z_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] .direction 
<<  endl ; 

//Update  the  global  array 

global2ktgrid [arrayindex] [column] .x_magnitude  = 
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nontubelevelgr id [array index] [column] .x_magnitude; 

global2ktgrid[arrayindex] [column] .y_magnitude  = 
nontubelevelgrid[arrayindex] [column] .y_magnitude; 

global2ktgrid [arrayindex] [column] . z_magnitude  = 
nontubelevelgrid[arrayindex] [column] . z_magnitude; 

global2ktgrid[arrayindex] [column] .direction  = 
nontubelevelgrid[arrayindex] [column] .direction; 

break; 
case  3 : 

plate3ktOutput  <<  arrayindex  <<  "  "  <<  column  <<  "  " 

<<  nontubelevelgrid [arrayindex] [column] .x_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] .y_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] . z_magnitude  << 

<<  nontubelevelgrid [arrayindex] [column] .direction 
<<  endl ; 

//Update  the  global  array 

global3ktgrid[ arrayindex] [column] .x_magnitude  = 
nontubelevelgrid [arrayindex] [column] .x_magnitude; 

global3ktgrid [arrayindex] [column] .y_magnitude  = 
nontubelevelgrid [arrayindex] [column] .y_magnitude; 

global3ktgrid [arrayindex] [column] . z_magnitude  = 
nontubelevelgrid [arrayindex] [column] . z_magnitude; 

global3ktgrid [arrayindex] [column] .direction    = 
nontubelevelgrid [arrayindex] [column] .direction- 
break; 
default: 

cerr  <<  "Invalid  Submarine  Speed"  <<  endl; 
break; 
}   //  end  switch 
}  //end  of  column  loop 
pass  +=  1; 

} 

//Fill  current  distance  array,  and  write  values  to  file 
nontubelevelgrid[current_distance] [i j ] .x_magnitude  =  0.0; 

nontubelevelgrid[current_distance] [ij ] .y_magnitude  =  -  U[ij]  *  submarine_speed; 
nontubelevelgrid [current_distance] [i j ] . z_magnitude  =  0.0; 
nontubelevelgrid[current_distance] [ij ] .direction  =  180.0; 

//This  section  adds  a  pump  inlet  180  ft  back  on  the  hull.  It  starts  out  at 
full 

//force  and  diminishes  to  0  at  20  ft  out  from  the  hull.  It  assumes  water  is 
sucked  in  at  2.5  kts 

if  ( (generationloop  >  suctionBegin_m)  &&  (generationloop  <  suctionEnd_m) )  { 
nontubelevelgrid [current_distance] [ij] .x_magnitude  = 
pump_inlet_jet_f actor 

*  pump_inlet_jet_speed; 

if  (pump_inlet_jet_f actor  <  -0.2)  { 

pump_inlet_jet_f actor  =  pump_inlet_jet_f actor  +  0.02  5; 

} 

else  { 

pump_inlet_jet_f actor  =  0.0; 

} 
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//This  section  adds  a  pump  discharge  jet  246  ft  back  on  the  hull.  It  starts 
out  at  full 

//force  and  diminishes  to  0  at  20  ft  out  from  the  hull. It  assumes  water  is 
discharged  in  at  2.5  kts 

else  if  ( (generationloop  >  dischargeBegin_m)  &&  (generationloop  < 
dischargeEnd_m) )  { 

nontubelevelgrid[current_distance] [ij] .x_magnitude  = 
pump_outlet_jet_f actor 

*  pump_outlet_jet_speed; 

if  (pump_outlet_jet_factor  >  0.2)  { 

pump_outlet_jet_f actor  =  pump_outlet_jet_f actor  -  0.025; 
} 
else  { 

pump_outlet_jet_f actor  =  0.0; 
} 


//Now  write  these  values  to  the  proper  file 
switch  ( ( int) submarine_speed)  { 
case  1 : 

platelktOutput  <<  current_distance  <<  "  "  <<  ij  <<  "  " 

<<  nontubelevelgrid[current_distance] [i j ] .x_magnitude  << 
<<  nontubelevelgrid[current_distance] [i j ] .y_magnitude  << 
<<  nontubelevelgrid[current_distance] [i j ] . z_magnitude  << 
<<  nontubelevelgrid[current_distance] [ij] .direction 
<<  endl ; 

//Update  the  global  array 

globallktgrid[current_distance] [ij] .x_magnitude  = 
nontubelevelgrid[current_distance] [ij] . x_magnitude; 

globallktgrid[current_distance] [ij] .y_magnitude  = 
nontubelevelgrid[current_distance] [ij] .y_magnitude; 

globallktgrid[current_distance] [ij ] . z_magnitude  = 
nontubelevelgrid[current_distance] [ij] . z_magnitude; 

globallktgrid[current_distance] [ij] .direction  = 
nontubelevelgrid[current_distance] [ij] .direction; 

break ; 
case  2 : 

plate2ktOutput  <<  current_distance  <<  "  "  <<  ij  <<  "  " 

<<  nontubelevelgrid[current_distance] [ij ] .x_magnitude  << 
<<  nontubelevelgrid[current_distance] [i j ] .y_magnitude  << 
<<  nontubelevelgrid[current_distance] [ij ] . z_magnitude  << 
<<  nontubelevelgrid[current_distance] [ij] .direction 
<<  endl ; 

//Update  the  global  array 

global2ktgrid[current_distance] [ij] .x_magnitude  = 
nontubelevelgrid[current_distance] [ij] .x_magnitude; 

global2ktgrid[current_distance] [ij] .y_magnitude  = 
nontubelevelgrid[current_distance] [ij] .y_magnitude; 

global2ktgrid[current_distance] [ij] .z_magnitude  = 
nontubelevelgrid[current_distance] [ij] . z_magnitude; 

global2ktgrid[current_distance] [ij] .direction  = 
nontubelevelgrid[current_distance] [ij] .direction; 

break ; 
case  3 : 

plate3ktOutput  <<  current_distance  <<  "  "  <<  ij  <<  "  " 

<<  nontubelevelgrid[current_distance] [i j ] .x_magnitude  << 
<<  nontubelevelgrid[current_distance] [i j ] .y_magnitude  << 
<<  nontubelevelgrid[current_distance] [ij ] . z_magnitude  << 
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<<  nontubelevelgrid[current_distance] [ij] .direction 
<<  endl; 

//Update  the  global  array 

global3ktgrid[current_distance] [ij] .x_magnitude  = 
nontubelevelgrid[current_distance] [ij] .x_magnitude; 

global3ktgrid[current_distance] [ij] .y_magnitude  = 
nontubelevelgrid[current_distance] [ij] .y_magnitude; 

global3ktgrid[current_distance] [ij] .z_magnitude  = 
nontubelevelgrid[current_distance] [ij] . z_magnitude; 

global3ktgrid[current_distance] [ij] .direction  = 
nontubelevelgrid[current_distance] [ij] .direction; 

break; 
default : 

cerr  <<  "Invalid  Submarine  Speed"  <<  endl; 
break ; 
}   //  end  switch 

pass  =  1; 

last_distance_f illed  =  current_distance; 

// 

//This  section  does  file  output  for  files  that  are  used  to  visualize 
//field  output  over  the  whole  sub  length.  They  are  generally  used  for 
//viewing  only.  This  data  is  not  in  a  UVW  usable  form 
if  (U[ij]  >=  0.99)    { 

plateProf ileOutput      <<  XF  <<  "  " 

«  Y[ij] 
<<  endl ; 
//firstEntry  =  0; 
} 

//Put  output  to  file  for  flat  plate  slice  at   50  ft 
if  ( (generationloop  ==  15)  &&  (submarine_speed  ==1))   { 
plateSlice50Output  <<  Y[ij]  <<  "  "  <<  U[ij]   <<  endl; 

} 

//Put  output  to  file  for  flat  plate  slice  at  100  ft 

if  ((generationloop  ==  30)  &&  (submarine_speed  ==1))   { 

plateSlicelOOOutput  <<  Y[ij]  «  "  "  «  U[ij]  «  endl; 
} 

//Put  output  to  file  for  flat  plate  slice  at  150  ft 
if  ((generationloop  ==  45)   &&  (submarine_speed  ==1))  { 

plateSlicel50Output  <<  Y[ij]  <<  "  ■  «  U[ij]   <<  endl; 
} 

//Put  output  to  file  for  flat  plate  slice  at200  ft 
if  ( (generationloop  ==  60)   &&  (submarine_speed  ==  1) )  { 

plateSlice200Output  «  Y[ij]  «  "  "  «  U[ij]   <<  endl; 
} 

//Put  output  to  file  for  flat  plate  slice  at  250  ft 
if  ((generationloop  ==  75)   &&  (submarine_speed  ==1))  { 

plateSlice250Output  «  Y[ij]  <<  "  "  «  U[ij]  «  endl; 
} 
} 

}  //end  of  generationloop 
}  //end  of  submarine_speed  loop 


//Close  all  output  files 
platelktOutput . close ( ) ; 


-192- 


plate2ktOutput . close ( ) ; 
plate3kt0utput . close ( ) ; 
plateProf ileOutput .close ( ) ; 
plateSlice50Output . close ( ) ; 
plateSlicelOOOutput . close ( ) 
plateSlicel50Output . close ( ) 
plateS lice2  00Output . close ( ) 
plateSlice250Output . close ( ) 
return; 


}   //end  of  flatPlate  function 


void 


tubeLevelFlowFieldGenerator  (  void  )  { 


// 

//Arrays  to  hold  all  values  as  they  are  modified 


FlowGridElements 
FlowGridElements 
FlowGridElements 
FlowGridElements 
FlowGridElements 

FlowGridElements 
FlowGridElements 
FlowGridElements 
FlowGridElements 
FlowGridElements 

FlowGridElements 
FlowGridElements 
FlowGridElements 
FlowGridElements 
FlowGridElements 


abovelkt 

upperlkt 

centerlkt 

lowerlkt 

belowlkt 

above2kt 

upper2kt 

center2kt 

lower2kt 

below2kt 

above3kt 
upper 3 kt 
center3kt 
lower3kt 
below3kt 


FLOWF I ELDLENGTH ] 
FLOWFIELDLENGTH] 
FLOWF I ELDLENGTH ] 
FLOWF I ELDLENGTH ] 
FLOWF I ELDLENGTH ] 

FLOWF I ELDLENGTH ] 
FLOWF I ELDLENGTH ] 
FLOWFIELDLENGTH] 
FLOWFIELDLENGTH] 
FLOWFIELDLENGTH] 

FLOWFIELDLENGTH] 
FLOWFIELDLENGTH] 
FLOWFIELDLENGTH] 
FLOWFIELDLENGTH ] 
FLOWF I ELDLENGTH] 


[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 

[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 

[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 
[FLOWFIELDWIDTH] 


1  kt. 


// 

//Output  streams  to  hold  the  generated  flow  fields  for  later  usage. 

//Five  files  are  created  for  each  sub  speed  to  cover  all  major  variations 

//  in  flow  profile. 

// 

// 

// 

// 

// 

// 

// 

//  the  lower  edge  of  the  tube  for  a  submarine  speed  of  1  kt . 

// 

// 

// 

//   Files  for  other  speeds  are  named  using  the  same  conventions. 


abovetubelevellkt .data  -  Holds  the  tube  model  flow  field  at 
1  ft  above  the  tube  using  a  submarine  speed  of  1  kt. 
uppertubelevellkt .data  -  Holds  the  tube  model  flow  field 

at  the  upper  edge  of  the  tube  for  a  submarine  speed  of 
centertubelevellkt .data  -  Holds  the  tube  model  flow  field  at 

the  center  of  the  tube  for  a  submarine  speed  of  3  kt . 
lower tube level Ik t .data  -  Holds  the  tube  model  flow  field  at 

the  lower  edge  of  the  tube  for  a  submarine  speed  of  1 
belowtubelevellkt .data  -  Holds  the  tube  model  flow  field  at 

1  ft  below  the  tube  using  a  submarine  speed  of  1  kt . 


ofstream  abovetubeLevellktOutput 
ofstream  upperLevellktOutput 
ofstream  centerLevellktOutput 
ofstream  lowertubeLevellktOutput 
ofstream  belowLevellktOutput 


( " above tube level lkt . data " , 
( "uppertubelevellkt .data" , 
( "centertubelevellkt .data' 
( "lowertubelevellkt .data"  , 
( "belowtubelevellkt .data" , 


lOS  : 

out)  ; 

ios : 

out)  ; 

lOS 

:out) 

ios : 

out)  ; 

ios : 

out)  ; 
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ofstream  abovetubeLevel2ktOutput 
ofstream  upperLevel2kt0utput 
ofstream  centerLevel2kt0utput 
ofstream  lowertubeLevel2kt0utput 
ofstream  belowLevel2ktOutput 

ofstream  abovetubeLevel3kt0utput 
ofstream  upperLevel3kt0utput 
ofstream  centerLevel3kt0utput 
ofstream  lowertubeLevel3kt0utput 
ofstream  belowLevel3kt0utput 


rabovetubelevel2kt .data" ,  ios : :out); 
'uppertubelevel2kt .data" ,  ios: :out); 
'center tube level 2 kt .data" ,  ios : : out) 
' lower tubelevel2kt .data" ,  ios : :out) ; 
'belowtubelevel2kt .data" ,  ios : :out) ; 

' abovetubelevel3kt .data" ,  ios: :out); 
'uppertubelevel3kt .data" ,  ios : : out) ; 
'centertubelevel3kt .data" ,  ios : :out) 
' lowertubelevel3kt .data" ,  ios : :out) ; 
'belowtubelevel3kt . data" ,  ios : : out) ; 


// 

//Initialize  the  tube  level  flow  fields  to  those  of  the  flat 
//Plate  fields 

for  (int  row  =  0;  row  <  FLOWFIELDLENGTH;  row++)   { 
for  (int  col  =  0;  col  <  FLOWFIELDWIDTH;  col++)   { 


abovelkt  [row] 

abovelkt  [row] 

abovelkt  [row] 

abovelkt  [row] 

upperlkt  [row] 

upperlkt  [row] 

upperlkt  [row] 

upperlkt  [row] 

centerlkt  [row 

centerlkt  [row 

centerlkt  [row 

centerlkt  [row 


lowerlkt 

row] 

lowerlkt 

row] 

lowerlkt 

row] 

lowerlkt 

row] 

belowlkt 

row] 

belowlkt 

row] 

belowlkt 

row] 

belowlkt 

row] 

above2kt 

row] 

above2kt 

row] 

above2kt 

row] 

above2kt 

row] 

upper 2 kt 

[row] 

upper 2 kt 

[row] 

upper2kt 

[row] 

upper2kt 

[row] 

center2kt 

[row 

center2kt 

[row 

center2kt 

[row 

center2kt 

[row 

lower 2 kt  [row] 

lower2kt  [row] 

lower2kt  [row] 

lower2kt  [row] 


col] .x_magnitude  - 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction    = 

col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction    = 

[col] .x_magnitude 
[col] .y_magnitude 
[col] .z_magnitude 
[col] .direction 

col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction   - 

col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction    = 


col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction   = 

col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction    = 

[col] .x_magnitude 
[col] .y_magnitude 
[col] .z_magnitude 
[col] .direction 

col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction    = 


globallktgrid [row] 
global lktgrid[ row] 
globallktgrid [row] 
globallktgrid [row] 

globallktgrid [row] 
globallktgrid [row] 
globallktgrid [row] 
globallktgrid [row] 

globallktgrid [row 
globallktgrid [row 
globallktgrid [row 
globallktgrid [row 

globallktgrid [row] 
globallktgrid [row] 
globallktgrid [row] 
globallktgrid [row] 

globallktgrid [row] 
globallktgrid [row] 
globallktgrid [row] 
globallktgrid [row] 


global 2 ktgr id [row] 
global2ktgrid [row] 
global2ktgrid [row] 
global2ktgrid[row] 

global 2 ktgr id [row] 
global2ktgrid[row] 
global2ktgrid[row] 
global2ktgrid[row] 

global2ktgrid[row 
global2ktgrid[row 
global 2 ktgr id [row 
global2ktgrid[row 

global2ktgrid [row] 
global2ktgrid [row] 
global2ktgrid[row] 
global2ktgrid[row] 


col] .x_magnitude 
col] .y_magnitude 
col] .z_magnitude 
col] .direction  ; 

col] .x_magnitude 
col] .y_magnitude 
col] . z_magnitude 
col] .direction  ; 

[col] .x_magnitude 
[col] .y_magnitude 
[col] .z_magnitude 
[col] . direction  ; 


col] 

.x_magnitude 

col] 

.y_magnitude 

col] 

. z_magnitude 

col] 

.direction  ; 

col] 

.x_magnitude 

col] 

.y_magnitude 

col] 

. z_magnitude 

col] 

.direction  ; 

col] 

. x_magni  tude 

col] 

.y_magnitude 

col] 

. z_magnitude 

col] 

.direction  ; 

col] 

.x_magnitude 

col] 

• y_magnitude 

col] 

. z_magnitude 

col] 

.direction  ; 

[col] .x_magnitude 
[col] .y_magnitude 
[col] .z_magnitude 
[col] .direction  ; 

col] .x_magnitude  ; 

col] .y_magnitude  ; 

col] . z_magnitude  ; 
col] .direction  ; 
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below2kt  [row] 

below2kt  [row] 

below2kt  [row] 

below2kt  [row] 


above3kt  [row] 

above3kt  [row] 

above3kt  [row] 

above3kt  [row] 

upper3kt  [row] 

upper3kt  [row] 

upper3kt  [row] 

upper3kt  [row] 

center3kt  [row 

center3kt  [row 

center3kt  [row 

center3kt  [row 

lower3kt  [row] 

lower3kt  [row] 

lower3kt  [row] 

lower3kt  [row] 

below3kt  [row] 

below3kt  [row] 

below3kt  [row] 

below3kt  [row] 


col] .x_magnitude 
col] . y_magnitude 
col] . z_magnitude 
col] .direction 


col] . x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction    = 

col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction   = 

[col] .x_magnitude  = 
[col] .y_magnitude  = 
[col] . z_magnitude  = 
[col] .direction   = 

col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction    = 

col] .x_magnitude  = 
col] .y_magnitude  = 
col] . z_magnitude  = 
col] .direction    = 


global2ktgrid[row] 
global 2 ktgr id [row] 
global 2 ktgr id [row] 
global2ktgrid [row] 


global3ktgrid[row] 
global 3 ktgr id [row] 
global3ktgrid[row] 
global3ktgrid [row] 

global3ktgrid[row] 
global3ktgrid[row] 
global 3 ktgr id [row] 
global3ktgrid[row] 

global3ktgrid [row 
global3ktgrid [row 
global3ktgrid [row 
global 3 ktgr id [row 

global3ktgrid [row] 
global3ktgrid [row] 
global3ktgrid [row] 
global 3 ktgr id [row] 

global3ktgrid [row] 
global3ktgrid [row] 
global3ktgrid [row] 
global3ktgrid [row] 


col] .x_magnitude 
col] .y_magnitude 
col] .z_magnitude 
col] .direction  ; 


col] .x_magnitude 
col] .y_magnitude 
col] .z_magnitude 
col] .direction  ; 

col] .x_magnitude 
col] .y_magnitude 
col] . z_magnitude 
col] .direction  ; 

[col] .x_magnitude 
[col] .y_magnitude 
[col] .z_magnitude 
[col] .direction  ; 


col] 
col] 
col] 
col] 

col] 
col] 
col] 
col] 


x_magnitude 
y_magnitude 
z_magnitude 
direction  ; 


x_magnitude 
y_magnitude 
z_magnitude 
direction  ; 


}   //End  of  col  loop 
}    //End  of  Row  loop 


// 

//Update  the  tube  level  flow  fields  to  show  the  tube  flow 

/ /disturbances 

double  before_tube_force  =  1.0; 

double  af ter_tube_force   =  -1.0; 


for  (int  along_hull  -    30;  along_hull  <=  60;  along_hull++)  { 
before_tube_force  =  1.0; 
for  (int  out_from_hull  =  0;  out_from_hull  <=  30  ;  out_from_hull++) 


abovelkt 

upperlkt 

centerlkt 

lowerlkt 

belowlkt 

above2kt 

upper2kt 

center2kt 

lower2kt 

below2kt 

above3kt 

upper 3 kt 

center3kt 

lower3kt 

below3kt 


[along, 
[along_ 
[along, 
[along, 
[along, 
[along, 
[along, 
[along, 
[along, 
[along, 
[along, 
[along, 
[along, 
[along, 
[along. 


hull 
hull 
hull 
hull 
hull 
hull 
hull 
hull 
hull 
hull 
hull 
hull 
hull 
hull 
hull 


out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

.from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

out. 

_from_hull] 

.x_magnitude 
.x_magnitude 
. x_magni  tude 
.x_magnitude 
.x_magnitude 
.x_magnitude 
.x_magnitude 
.x_magnitude 
. x_magni  tude 
.x_magnitude 
. x_magni  tude 
.x_magnitude 
.x_magnitude 
.x_magnitude 
. x_magni  tude 


before, 
before, 
before, 
before, 
before, 
before, 
before, 
before, 
before, 
before, 
before, 
before, 
before, 
before, 
before 


tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube, 
tube 


{ 

.force 
.force 
.force 
.force 
.force 
.force 
.force 
.force 
.force 
.force 
.force 
.force 
.force 
.force 
force 


before_tube_force  =  before  tube  force 


0.032; 
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for  (  along_hull  =  61;  along_hull  <=  80;  along_hull++)  { 
af ter_tube_force  =  -1.0; 
for  (int  out_from_hull  =  0;  out_from_hull  <=  30  ;  out_from_hull++) 


abovelkt 

along. 

.hull] 

[out. 

_from_hull 

. x_magnitude 

= 

after. 

.tube. 

.force 

* 

1 

upper lkt 

along_ 

.hull] 

[out. 

.from_hull 

. x_magnitude 

= 

after. 

.tube. 

.force 

* 

1 

centerlkt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

1 

lowerlkt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

1 

belowlkt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

1 

above2kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

2 

upper2kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

2 

center2kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

2 

lower2kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

2 

below2kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

2 

above3kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

3 

upper 3 kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

3 

center3kt 

along. 

hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

3 

lower3kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

3 

below3kt 

along. 

.hull] 

[out. 

_from_hull 

.x_magnitude 

= 

after. 

.tube. 

.force 

* 

3 

af ter_tube_force  =  af ter_tube_force  +  0.032; 


// 

//Output  the  flow  field  arrays  to  the  proper  files 
for  (int  rowl  =  0;  rowl  <  FLOWFIELDLENGTH;  rowl++)   { 
for  (int  coll  =  0;  coll  <  FLOWFIELDWIDTH;  coll++)   { 

abovetubeLevellktOutput  <<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  abovelkt  [rowl] [coll] .x_magnitude 

<<  abovelkt  [rowl] [coll] .y_magnitude 

<<  abovelkt  [rowl]  [coll]  . z_magnitude 

<<  abovelkt  [rowl] [coll] .direction 


upperLeve 1 1 k tOu  tpu  t 


centerLevellktOutput 


<<  rowl  <<  "  "  <<  coll  <<  "  " 
«  upper lkt  [rowl] [coll] .x_magnitude 
<<  upperlkt  [rowl] [coll] .y_magnitude 
«  upperlkt  [rowl] [coll] . z_magnitude 
<<  upperlkt  [rowl] [coll] .direction 


<< 

II   II 

<< 

II  I. 

<< 

„  I. 

<< 

endl 

<< 

,.  „ 

<< 

■  " 

<< 

„  i, 

<<  endl i 


<<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  centerlkt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  centerlkt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  centerlkt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  centerlkt  [rowl] [coll] .direction   <<  endl; 

lowertubeLevellktOutput  «  rowl  <<  "  "  <<  coll  <<  "  " 

<<  lowerlkt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  lowerlkt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  lowerlkt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  lowerlkt  [rowl] [coll] .direction  <<  endl; 


belowLevellktOutput 


«  rowl  << 


<<  coll  << 


<<  belowlkt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  belowlkt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  belowlkt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  belowlkt  [rowl] [coll] .direction   <<  endl, 

abovetubeLevel2ktOutput  <<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  above2kt  [rowl] [coll] .x_magnitude   <<  "  " 


196- 


<<  above2kt  [rowl] [coll] .y_magnitude  <<  "  " 
<<  above2kt  [rowl] [coll] . z_magnitude  <<  "  " 
<<  above2kt  [rowl]  [coll] .direction    <<  endl ; 


upper Leve 1 2  ktOu tput 


centerLevel2kt0utput 


<<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  upper2kt  [rowl]  [coll]  .x_magnitude  <<  "  " 

<<  upper2kt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  upper2kt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  upper2kt  [rowl] [coll] .direction  <<  endl; 

<<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  center2kt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  center2kt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  center2kt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  center2kt  [rowl] [coll] .direction  <<  endl, 


lowertubeLevel2kt0utput  <<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  lower2kt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  lower2kt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  lower2kt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  lower2kt  [rowl]  [coll]  .direction  <<  endl, 


belowLevel2ktOutput 


<<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  below2kt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  below2kt  [rowl]  [coll]  .y_magnitude  <<  "  " 

<<  below2kt  [rowl]  [coll]  . z_magnitude  <<  "  " 

<<  below2kt  [rowl] [coll] .direction  <<  endl; 


upperLevel3kt0utput 


centerLevel3kt0utput 


<< 

endl  ; 

<< 

,,  „ 

<< 

„  > 

<< 

„  ,, 

<< 

endl ; 

abovetubeLevel3kt0utput  <<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  above3kt  [rowl] [coll] .x_magnitude  << 
<<  above3kt  [rowl] [coll] .y_magnitude  << 
<<  above3kt  [rowl] [coll] . z_magnitude  << 
<<  above3kt  [rowl] [coll] .direction 

<<  rowl  <<  "  "  <<  coll  <<  "  " 
<<  upper3kt  [rowl] [coll] .x_magnitude 
<<  upper3kt  [rowl] [coll] .y_magnitude 
<<  upper3kt  [rowl] [coll] .z_magnitude 
<<  upper3kt  [rowl] [coll] .direction 

<<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  center3kt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  center3kt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  center3kt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  center3kt  [rowl] [coll] .direction   <<  endl; 

lowertubeLevel3ktOutput  <<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  lower3kt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  lower3kt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  lower3kt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  lower3kt  [rowl] [coll] .direction   <<  endl; 


belowLevel3kt0utput 


<<  rowl  <<  "  "  <<  coll  <<  "  " 

<<  below3kt  [rowl] [coll] .x_magnitude  <<  "  " 

<<  below3kt  [rowl] [coll] .y_magnitude  <<  "  " 

<<  below3kt  [rowl] [coll] . z_magnitude  <<  "  " 

<<  below3kt  [rowl] [coll] .direction  <<  endl, 


}   //End  of  coll  loop 
}    //End  of  Rowl  loop 


//■ 
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//Close  all  Files  for  later  use  by  dynamics /gnuplot 
abovetubeLevellktOutput . close ( ) ; 
upperLevellktOutput . close ( ) ; 
centerLevellktOutput .close ( ) ; 
lower tubeLevellktOutput . close ( )  ; 
belowLevellktOutput . close ( ) ; 

abovetubeLevel2ktOutput . close ( )  ; 
upperLevel2ktOutput . close ( ) ; 
centerLevel2ktOutput . close ( ) ; 
lowertubeLevel2ktOutput .close ( ) ; 
belowLevel2ktOutput .close ( ) ; 

abovetubeLevel3kt0utput . close ( ) ; 
upperLevel3ktOutput . close ( ) ; 
centerLevel3ktOutput .close ( ) ; 
lowertubeLevel3ktOutput .close ( ) ; 
belowLevel3kt0utput .close ( ) ; 


return; 


// 

//This  is  the  driver  to  run  the   flateplate  flow  generation  and 
//tube  level  flow  generation  functions 
main  ( )  { 

cout  <<  "Starting  the  Flow  Field  Generation  program."  <<  endl; 

cout  <<  "Generating  the  Flow  Profiles  for  the  Flat  Plate  Model  Area."  <<  endl; 
f latPlateFlowFieldGenerator  (  ) ; 


endl  ; 


cout  <<  endl  <<  endl; 

cout  <<  "The  following  File(s)  were  created  for  use  by  the  Phoenix  AUV  UVW: 


cout  << 
cout  << 
cout  << 

cout  << 
cout  << 
cout  << 
cout  << 
cout  << 
cout  << 
cout  <<  endl  <<  endl, 


flatplateflowfieldlkt.data"  «  endl 
f latplatef lowf ield2kt .data"  <<  endl 
f latplatef lowf ield3kt .data"  <<  endl 

f latprof ile.data"  <<  endl; 
f latslice50 .data"  <<  endl; 
f latslicelOO .data"  <<  endl 
f latslicel50 .data"  <<  endl 
flatslice200.data"  «  endl 
flatslice250.data"    «  endl 


endl  ; 


cout  <<  "Creating  the  Flow  Profiles  for  the  Tube  Level  Flow  Areas."  <<  endl; 

tubeLevelFlowFieldGenerator  ( ) ; 

cout  <<  "The  following  File(s)  were  created  for  use  by  the  Phoenix  AUV  UVW: 


cout  <<  " 

cout  <<  " 

cout  <<  " 

cout  <<  " 

cout  <<  " 

cout  <<  endl ; 

cout  <<  " 

cout  <<  " 

cout  <<  " 


abovetubelevellkt .data"  <<  endl; 
uppertubelevellkt .data"  <<  endl; 
centertubelevellkt .data"  <<  endl; 
lowertubelevellkt .data"  <<  endl; 
belowtubelevellkt .data"  <<  endl; 

abovetubelevel2kt .data"  <<  endl; 
uppertubelevel2kt .data"  <<  endl; 
centertubelevel2kt .data"  <<  endl, 
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cout  <<  " 

cout  <<  ■ 

cout  <<  endl; 

cout  <<  " 

cout  <<  " 

cout  <<  " 

cout  <<  " 

cout  <<  " 

cout  <<  endl  <<  endl ; 


lowertubelevel2kt .data"  <<  endl; 

belowtubelevel2kt .data"  <<  endl; 

abovetubelevel3kt .data"  <<  endl; 

uppertubelevel3kt .data"  <<  endl; 
centertubelevel3kt . data"  <<  endl; 

lowertubelevel3kt . data"  <<  endl; 

belowtubelevel3kt .data"  <<  endl; 


cout  <<  "Exiting  the  Flow  Field  Generation  Program."  <<  endl; 


return  0 ; 
}   //  end  main 
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APPENDIX  E.  SIMULATION  VIDEO 

1.  INTRODUCTION 

The  attached  video  appendix  gives  an  overall  view  of  the  Phoenix  AUV  virtual  environment. 
All  major  objects  are  described  and  viewed. 

2.  SURFACE  BUOYANCY  AND  WAVE  MOTION 

In  this  segment  the  AUV  is  run  on  a  course  into  the  seas  in  various  sea  states.  The  test  runs 
demonstrate  a  sea  state  of  1,  3,  and  5  respectively. 

3.  PUMP  OUTLETS/INLETS 

This  part  of  the  demonstration  shows  the  AUV  driving  past  a  pump  discharge  outlet  followed 
by  a  pump  suction  inlet.  It  demonstrates  how  the  effects  of  turbulent  flow  are  felt  by  the  AUV,  and 
how  the  AUV  maintains  stability  and  continues  on  the  preplanned  course. 

4.  COMPLETE  MISSION 

This  is  the  final  portion  of  the  simulation  tape.  It  shows  a  complete  torpedo  tube  launch  and 
recovery  mission.  The  AUV  is  launched  from  a  lower  port  torpedo  tube,  proceeds  into  the  open  water, 
takes  position  at  the  submarines  stern  and  then  conducts  a  docking  evolution  with  the  upper  port 
torpedo  tube.  Both  inward  and  outward  outer  door  openings  are  assumed,  ans  simply  represented 
using  cylinders. 

5.  INVOCATION  INSTRUCTIONS 

To  reproduce  this  mission  the  following  steps  should  be  taken. 
A.         Start  the  viewer  application  as  follows. 

SGI>  viewer 
2.  Start  the  dynamics  portion  of  the  program  as  follows 

SGI>  dynamics 
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OR 

SGI>  dynamic s_nosonar 


*****Insert  dynamics  Menu  Capture****** 


*** 


C.  After  dynamics  is  running  select  the  option  to  conduct  a  torpedo  tube  docking 
evolution  (it  is  letter  "z"). 

D.  Once  all  flow  field  arrays  are  initialized,  select  "1"  to  loop  the  dynamics  with  the 
execution  level. 

E.  Finally,  launch  the  execution  application  as  follows: 

SGI>  execution  mission  mission. script . FlowFieldGenerator 
remote  <dynamics  host  name> 

F.  You  should  now  observe  a  torpedo  tube  launch  and  recovery  mission  in  the  viewer. 
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